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 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++.

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.