aldous
Active Member
For the past few months, I've been looking for evidence that Apple have screwed up - as that article implies - but haven't found any so far.I skimmed that site a while ago, and - no offense to Blue Cat - I wasn't sure how worried to be today.
In 2020 Apple says, "you must do X* to protect performance." There's a good reason** they did this. Apple usually gives two years' notice of breaking changes, so it seems a bit rich for developers to do nothing about it and then go all Pikachu-faced in 2023 when performance suffers.
The linked article says "X looked like an optional feature" immediately below the video that explicitly says it isn't optional. I found documentation for the things it said weren't documented. Others claim the API's buggy, but nobody has yet been willing/able to say what the bugs are; and I've seen working implementations of all the main operating modes.
Not saying that it's totally trivial, BTW, especially for plugins written once and compiled to many formats/platforms. Looks like JUCE only got updated at the end of last year, so it will be a while before that code makes it to developers who couldn't/didn't want to address the issue directly. After that, it still has to get through developers' regular patch and release cycles (some more regular than others!)... so, could be a while before it reaches users.
* where X = "add additional real-time audio processing threads to the audio device's workgroup". MacOS does this automatically for the 'default' thread, so most(?) plugins with only one real-time thread required no action. Some of the issues are a bit subtle, but anyone writing a plugin with multiple r/t threads must already know what they're doing: otherwise, it's like giving a grenade launcher to a chimp. Apple warns developers of this (admittedly, using different terminology.)
** if you have lots of real-time threads potentially in different processes (e.g. in a multi-architecture DAW with lots of plugins!), the OS needs to know how those threads cooperate to produce their audio. It can't work this out automatically; priority and QoS flags aren't expressive enough; and letting the scheduling order emerge organically from the usual concurrency primitives is far too slow. "Audio workgroups" is a mechanism that allows developers of multi-RT-threaded plugins to tell the OS what it needs to know.
** if you have lots of real-time threads potentially in different processes (e.g. in a multi-architecture DAW with lots of plugins!), the OS needs to know how those threads cooperate to produce their audio. It can't work this out automatically; priority and QoS flags aren't expressive enough; and letting the scheduling order emerge organically from the usual concurrency primitives is far too slow. "Audio workgroups" is a mechanism that allows developers of multi-RT-threaded plugins to tell the OS what it needs to know.