Catalina: Apple turns macOS into a closed platform; many audio-devs warned from the upgrade

[Vokbuz]

The key point is: when a plug-in format is developed by the same company as the OS, integration between the OS and the plug-in format is both easier and more solid than when OS and the plug-in technology come from different companies. Common sense.

What is an integration between OS and plugin? AudioUnits are a part of a platform framework, it can use AudioUnits to form processing graph for applications. Do you mean this integration? But this feature makes AU an overkill for audio plugins loaded in DAW. It is too complicated. DAWs simply don't need all of these.

Apart from this, I personally don't find AUs integration in OS any better. Try to have objective-c classes in different plugins with same names but different implementations and you will stop finding integration with OS that good.

Also, giving the fact that most plugins are multi-platform, all those platform specific features simply do not add anything to an average developer.

[Hanz Meyzer]

C'mon, stratology has no idea what he is talking about. He always finds dummy arguments for Apple. Better do not waste your time with a discussion here. His view is not based on logic and common sense.

[stratology]

VST is world standard
..
Avid is used by old men
..
I am also pretty sure they try to opensource as few as possible and as outdated as possible.

then:

C'mon, stratology has no idea what he is talking about. He always finds dummy arguments for Apple. Better do not waste your time with a discussion here. His view is not based on logic and common sense.

Admittedly, I cannot match the technical brilliance and deep insight of your points.

Apple replacing an existing, widely adopted, proven technology (AU) with technology that does exactly the same for end users (VST), but is licensed from a competitor - a true common sense proposal, if I ever heard one.

[Hanz Meyzer]

LOL you are just ignoring reality.

[fmr]

Apple replacing an existing, widely adopted, proven technology (AU) with technology that does exactly the same for end users (VST), but is licensed from a competitor - a true common sense proposal, if I ever heard one.

So, you admit that Apple created AU just because it doesn't want to use technology licensed from a competitor. I left out the "widely adopted, proven technology (AU)" because of the obvious nonsense.

Now imagine (just imagine) that ANY host developer would think the same, and act the same.

[Angus_FX]

I wrote DX hosting in a few apps and so far as I could see, hosting a DX plugin seemed about equally CPU efficient, and about equally difficult to write code for, compared to VST. Am not bemoaning DX demise. There must have been good reasons but DX did not seem a "plainly obvious complete dog" compared to VST 2.x.

The problem with DX was that it was a gigantic breeding-ground for bugs due to being an insanely flexible spec and therefore many, many edge-cases and different ways to interpret it; worse, there was no canonical host implementation.

VST2 is simple and solid, and remains good, popular spec even after all Steinberg's attempts to kill it, precisely because of that. All the bits that 95% of the market uses can be implemented in a single header file of a couple of hundred lines. The same could be argued for MIDI, in fact. A plug-in API should aim to be like an audio connector: just enough pins to do the job. As the complexity goes up, the potential number of ways to get things wrong grows exponentially.

The more sophisticated the API, the more ways there are to get it wrong. AU just-about gets away with it, by being very focused on synchronous audio (DX could do all sorts of fancy async stuff, and video, and format-conversion), and by not messing around with MIDI. (Also, with Apple in control of it, Logic/GB have a fairly strong position as canonical host implementations: do it like us or you're wrong). AAX is only used in Pro Tools for the most part (OK, Avid runs it on some other software/hardware but they're not really our market) so isn't really trying to be a standard as such.

[Angus_FX]

Now imagine (just imagine) that ANY host developer would think the same, and act the same.

AVID?

[mystran]

What is an integration between OS and plugin? AudioUnits are a part of a platform framework, it can use AudioUnits to form processing graph for applications. Do you mean this integration? But this feature makes AU an overkill for audio plugins loaded in DAW. It is too complicated.

AU is an example of a plugin API that somehow works despite being complete rubbish. The whole processing graph for example is worse than useless; it's pure overhead.

In just about any reasonable modern multi-threaded audio engine design, you're going to be solving your graph dependencies before you even start processing anything, then scheduling the nodes on some fixed-size thread-pool as their dependencies become available. There are several ways to do this, but none of them benefit from the type of processing graph that AU wants you to use.

Realistically, by the time you're actually scheduling a node that wants to host an AU plugin, all the input data is already sitting in some simple buffer ready to use. At this point, if the plugin wants a "processing graph" so it can "pull inputs" you're almost certainly just going to supply it with a dummy graph with a dummy node that exists for the purpose of letting the plugin "pull" the data from the input buffers you already have waiting. I wouldn't exactly be surprised if even Logic did this internally.

Modern systems are fast enough that the overhead of all this non-sense is negligible, but it's still entirely pointless.

[Vokbuz]

The whole processing graph for example is worse than useless; it's pure overhead.
...
There are several ways to do this, but none of them benefit from the type of processing graph that AU wants you to use.

Exactly. Things are better in AUv3 though.

[stratology]

AudioUnits are a part of a platform framework, it can use AudioUnits to form processing graph for applications.

...

Things are better in AUv3 though.

AUGraph has been deprecated this year - not sure if that's what you're referring to..
https://developer.apple.com/videos/play/wwdc2019/508/


Thanks for the insightful posts.

[syntonica]

The problem with DX was that it was a gigantic breeding-ground for bugs due to being an insanely flexible spec and therefore many, many edge-cases and different ways to interpret it; worse, there was no canonical host implementation.

VST2 is simple and solid, and remains good, popular spec even after all Steinberg's attempts to kill it, precisely because of that.

Not really. There so many differences in host implementations that there's DAW-specific code in most VSTs. The only reason it's popular is just because VST 2.4 is a fully known quantity. VST 2.4 is starting to get crufty and it's time to move on.

One of these days, I'll get around to looking at VST3 to see what it has to offer, but only when all DAWs support it.

I've glanced at the AU spec and once again, for better or worse, it's Apple's way or the highway. I've given up on the idea of a VST->AU wrapper, so idea number two is to just do a rewrite in Swift to a) learn Swift b) learn AU and c) compare the Swift speed vs the C++ speed. This will also give me the opportunity to look into iOS development.

[Vokbuz]

AUGraph has been deprecated this year - not sure if that's what you're referring to..
https://developer.apple.com/videos/play/wwdc2019/508/

Thanks for the insightful posts.

You don't need AUGraph to create processing graph with AU. Actually I never saw real use of AUGraph, only in online examples. Maybe it is/was used somewhere though.

[Angus_FX]

Not really. There so many differences in host implementations that there's DAW-specific code in most VSTs. The only reason it's popular is just because VST 2.4 is a fully known quantity. VST 2.4 is starting to get crufty and it's time to move on.

One of these days, I'll get around to looking at VST3 to see what it has to offer, but only when all DAWs support it.

But the knowability relates directly to the complexity.. we know all the ways in which MIDI can go wrong, and most of the ways VST2.4 can go wrong. DirectX was so large that, even if it had carried on in active use until now, we still wouldn't know all the ways it can go wrong.

VST3 is a rather more complex object-oriented API, as such there are many more ways it can go wrong.

I don't claim that 2.4 is by any means perfection, could easily reel off a dozen or more things wrong with it, but it's the least-worst by some margin.

AU is relatively clean at the underlying API level, but the amount of base classes and boilerplate code you need to support it is concerning. It's entirely reasonable that Apple would want to control their own standard for plug-in hosting, but a shame they couldn't come up with a simpler / cleaner implementation. (AAX is actually pretty cleanly done on that front, if it weren't a) proprietary, b) infected with PACE, it'd be quite a nice API).

[syntonica]

I don't claim that 2.4 is by any means perfection, could easily reel off a dozen or more things wrong with it, but it's the least-worst by some margin.

Vote for me! I'm the least Evil™!

AU is relatively clean at the underlying API level, but the amount of base classes and boilerplate code you need to support it is concerning.

That's what's so off-putting. Do I really need factories to create a single GUI instance for a single GUI plugin? I do all my own GUI drawing in raster with my own callbacks, etc., and I'm not sure how my paradigm will fit Apple's. If I remember correctly, last time I tried to wrap my VST version as AU, it failed validation since my parameter return values were not static, so it'll probably take some workaround to get past that.

ObjC is a fine language, but it's slow due to the runtime binding. And I'm not sure why Apple feels the need to overly complicate their classes. Some of theirs rival Java's in the WTF?!? were they thinking department. Hopefully, as the OS gets more "Swiftified", a lot of this complexity will drop out and leave just the essential.

But to my non-sequitur point, I always thought there should be a standard for "this is the API" for midi/audio, how you implement it for your host is up to you. I don't need to see the man behind behind the curtain, or even deal with him. I just want to plug in my code. VST 2 almost does this, but like I said, it's getting quite long in the tooth.

Just give me a window to use, a buffer of audio data and a buffer of MIDI data and I'm happy! I'll fill in some constants about what I am and what I do, and I'll handle presets, tyvm! I'm not sure why anybody would want to complicate it beyond that.

[mystran]

That's what's so off-putting. Do I really need factories to create a single GUI instance for a single GUI plugin? I do all my own GUI drawing in raster with my own callbacks, etc., and I'm not sure how my paradigm will fit Apple's. If I remember correctly, last time I tried to wrap my VST version as AU, it failed validation since my parameter return values were not static, so it'll probably take some workaround to get past that.

You can put AU and it's GUI into the same .dylib, which can also double as a VST. Just use the iPlug approach where your AU wrapper implements a custom property that your GUI factory uses to fetch a direct pointer to the actual plugin, so rest of your codebase can largely ignore all Apple non-sense.