holy_city

technically there is a DSP scripting language in Bitwig that isn't public but you can find some examples floating around online.

That said mixing DSP + UI is hard, and if you want to make the scripting user accessible it makes sense to keep them totally divorced.

I wrote this crate [1] as a compressor in Rust which is the opposite of a noise gate, as in gain reduction is applied after a threshold is passed instead of gain reduction applied if it is under a threshold.

If you want a really great approach to noise gating, a fixed threshold is fine but it works better when you apply it to the difference of two envelope followers - one with a short attack, long release (tracks input) and long attack, short release (tracks noise floor). Takes a bit to set it up, but it's a stupid simple way to get extremely effective gating and is easy to fine tune for your application. A lot of Voice Activity Detection (VAD) works this way; it's just a matter of tuning the coefficients and thresholds for your input.

Also useful reference for envelope following are the DAFX text [2], Will Pirkle's textbook on audio in C++ [3] and Zölzer's text [4]

[1] https://github.com/m-hilgendorf/rusty-compressor

[2] https://www.amazon.com/DAFX-Digital-Effects-Udo-Z%C3%B6lzer/...

[3] https://www.amazon.com/Designing-Audio-Effect-Plugins-C/dp/1...

[4] https://www.amazon.com/Digital-Audio-Signal-Processing-Z%C3%...

(pdfs can be found around the internet)

I wouldn't say std::mem::drop acts like free at all, it's the equivalent of a destructor in C++. Mostly useful when you're dealing with manually allocated memory, FFI, implementing an RAII pattern, etc.

One cool thing about Drop (and some other cool stuff, like MaybeUninit) is that it makes doing things like allocating/freeing in place just like any other Rust code. There may be some unsafe involved, but the syntax is consistent. Whereas in C++ seeing placement new and manually called destructors can raise eyebrows.

thank you!

Is the ABI documented anywhere? Every time I google around for it, I just get information like "COM is ABI stable and language agnostic" but not what the ABI is. I've successfully implemented implementations of single COM interfaces and get the basics, my trouble was in implementing many interfaces for the same implementation and running into copious segfaults when testing the Rust implementation through a reference app written in C++.

My issue isn't ABI stability but the ABI itself w.r.t vtable layout. Best I can tell it should be similar to Itanium's spec? [1]. It's been months since I did this, but iirc my problems stemmed from having multiple interfaces on top of the same implementation and the ordering/layout of those interfaces, though the IUnknown interface which is supposed to handle that.

[1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vtable

This is similar to the work done in winapi [1], com-imp[2] and my own tangential work on porting VST3 [3] to Rust [4]

I'm really glad MS is doing this. What needs to be a bit clearer to me is how they maintain ABI compatibility under the hood of MSVC for COM interfaces (which uses the vtable layout of an inherited class) and how that's compatible with MinGW/GCC stacks on Windows, mostly what can break it. I got stuck porting VST3 with multiple inheritance, and it was a headache trying to reverse engineer the appropriate struct layouts for COM implementations.

[1] https://github.com/retep998/winapi-rs/blob/0.3/src/macros.rs

[2] https://github.com/Connicpu/com-impl

[3] https://github.com/steinbergmedia/vst3sdk

[4] https://github.com/m-hilgendorf/cli-host (sorry for the messy code, it was a weekend of hacking away trying to host a VST3 in pure Rust)

A bigger issue I've seen is that "gut feeling" comes from a misplaced sense of confidence. Like say, sample size. I can't tell you how many times I've heard engineers say "the data isn't significant because the sample size is too small." If you have the data, calculate the confidence interval!

Most of the time you don't need hundreds to thousands of data points to be reasonably confident, just a few dozen. I remember the example distinctly from my sophomore engineering stats course, I don't know why everyone else has forgotten it.

Tencent has about a 5% stake iirc. They also have small interests in Activision-Blizzard and a big chunk of Epic. I have no idea what 5% of a company buys them.

That's fair. Pro Tools crashing during a session has been a meme for awhile, despite it being pretty stable for the last 5-ish years.

But keep in mind these companies are usually pretty small, a lot of sole-proprietors out there, and their revenue comes from new products/sales not maintaining projects. So there's logistical and incentive problems in deploying fixes quickly.

I mean most software that's currently maintained has been 64-bit ready for a decade. The issue is that there's a lot of 3rd party ghostware that isn't, and 32 bit bridging to support that code has been popular for awhile.

That software is a lot like vintage gear, there may be alternatives but they aren't the same, and that's the problem.

Waves sent one out last month as well. Par for the course really. Audio pros are some of the most distrustful users w.r.t updates because they've been burned so many times.

>So in this example, half of the putative "gain" is actually inflation.

Is this an issue in practice? Like I get if I have an asset that meets inflation for a decade than I'll lose value through the taxation. But that would be a bad investment, wouldn't it?

I don't think you could say CG taxes are "double taxation" since only the income from the asset is taxed, not the principle.

>it's much less than that because of inflation

Why would you hold an investment for 55 years that isn't beating inflation?

>the chances of me being attacked are practically zero

That's because the OS developers have placed value on security over performance. Whooping cough is rare too, we still vaccinate against it.

If you want a classic example, bounds checking an array is important to avoid RCE and sandbox escape attempts. It can also have a hefty performance penalty, under some scenarios it trashes the branch predictor/instruction pipeline. But I'm glad that my browser isn't as fast as machine-ly possible when streaming video, because I'd prefer if there wasn't a risk of having my emails from various banks, stored passwords in the browser, etc from being collected and sent to a bad actor.

Yes, my preferred way of looking at chords is superimposed intervals. The four chord qualities (major, minor, augmented, diminished) are built like:

- Diminished: Minor Third + Minor Third

- Minor: Minor 3rd + Major Third

- Major: Major 3rd + Minor Third

- Augmented: Major Third + Major Third

With the intervals being between the tonic and third, third and fifth. So for your example, that would be A, C, Eb as a diminished triad.

(not an economist but I'm really interested in this)

What's the difference in theory and practice between UBI and changing the standard deduction/marginal rate? Like if we give out $6k a year to everyone through a $500 check, what is the difference in how that money is spent versus if we increased the standard deduction to where people would pay $6k less in taxes? (assuming that people are in fact paying at least $6k)

I get that this is partly an experiment to figure this out, but what does the current theory say?

It's not half diminished though, since there's no 7? I'm talking about just the diminished triad (min 3rd + min 3rd). It's been years since I read jazz notation (classical background), but I thought that was just written "dim"

This is really cool! I think the chord naming has some bugs, but it's been awhile since I studied theory. For example all the diminished triads are labeled "min 7-5" which is kind of alien to me (and wrong, there's no 7), shouldn't it be "dim" or "o"?

Feature request: viewing the intervals on a keyboard/fretboard, with different colors/numbering for each scale degree.

New calendar app: Priority Inversion

It's interesting that Uber decided to merge their apps (Uber + Uber Eats) while FB seems to want to create more.

Personally I don't care about app count, I'm just not a huge fan of when companies spin features off as products unless it makes total sense. I think it does in this case, it looks like a crossover of Messenger and Instagram that reminds me of Snapchat when it was just a sexting app.

This has always bothered me. I don't like incurring a tax penalty that has to be paid in cash, when I don't have any more cash to pay it or a way to turn the asset into cash!

Sidenote: how do you actually determine the spread for tax purposes when you can't sell the stock/it doesn't have a current price?

I disagree, screen real estate is precious.

Consumer (and I assume commercial) bread machines often have a "dough only" cycle that you can use for automating your dough process. But I'd like one with a water filter and more granular control over the germ time, temperature, rise time, and knead strength/time all in one widget. Something with multiple wet/dry hampers and a programmable cycle would be really cool too.

See I don't like this attitude towards tax incentives because you're missing the tree for the woods.

This solution pays me for my inconvenience. It doesn't prevent the inconvenience in the first place or from happening again.

I don't think that making a luxury service more expensive will discourage use, unless we can make each flight cost tens of thousands of dollars.

I'd rather just ban assholery than create a steep asshole tax. It doesn't bother me that a few rich people will have to wait in traffic like everyone else (or better - stop traveling for cross-town meetings and take a phone call!).

Leave low altitude flight to emergency services.

I'm an LA resident and there's not many kinds of businesses I think should be categorically banned, but helicopter transit is one of them. It's a public nuisance. I will regularly need to interrupt phone conversations to let a helicopter pass over, which is sometimes impossible when they decide to hover (though this is usually police helicopters).

Well a lot of those activities are paid too. Marching bands get paid. Tutors get paid.

>People like analog synths because they have a very simple programming model that only makes a relatively small range of sounds, most of which sound good more or less by default. You trade immediacy against sophistication.

Well and they sound completely different.

The UI differences don't come down to number of controls but the fact that most analog designs have a 1:1 relationship with the sound, every knob you turn has a very distinct impact on the sound and usually, applying that to any input generates more or less the same impact on the output. It's extremely intuitive to learn how changing a knob changes the sound.

FM is completely different, where altering simple things like the operator ratios and modulation index have massive changes on the sound and don't create the same effect on different sounds - it's naturally non-intuitive. Most FM wizards get there through tons of experimentation, not through established fundamentals.

Imagine playing a wind instrument and changing your embouchure alters the pitch of the differently depending on what note you finger. That's what programming an FM synth is like.

iPad synths are a dime a dozen these days. Lack of a physical interface is as big a problem on them as with larger synths. They are hardly tactile.

A corollary here is the success of wavetable synths compared to granular, additive, and FM in the softsynth space. Wavetables have the same subtractive model as traditional analogs, and incorporate many of the same features as semi-modular synths. But they are extremely versatile because of how their interface is intuitive even for first time users - it's stupid easy to change the sound, the only additional dimension is the wavetable but that's quick to pick up. Compared to say, granular synths which are possibly the most versatile paradigm, but whose controls are extremely divorced from the timbre of the sound you design.

I feel like they missed the opportunity to name it None More Black [1].

[1] https://www.youtube.com/watch?v=zSkGtW-fQ3s