There is a lot of good news in open source audio these days. Also see this video presenting the work done and planned for the future version 4 of Audacity: https://www.youtube.com/watch?v=QYM3TWf_G38
yep, having gone through implementation of pretty much every plug-in api in existence in https://ossia.io there's no question that the whole world should just drop VST3 and move on to CLAP
That's very interesting news. Definitely brought on by CLAP as others have mentioned, but it's interesting to see how this evolves. VST is a pretty complicated standard to support whereas CLAP is much simpler, although the former is much more widely used.
I'm going to file this under "examples of Yamaha doing the right thing" (Steinberg is owned by Yamaha)
previous examples:
* Yamaha saved Korg by buying it when it was in financial trouble and giving it a cash injection, only to then sell it back to its previous owners once they had enough cash[1].
* Yamaha in the 80's had acquired Sequential (for those not familiar: Sequential Circuits is one of the most admired synthesizer makers). Many years later, Sequential's founder Dave Smith established a new company under a different name and in 2015 Yamaha decided to return the rights to use the Sequential brand to Smith, as a gesture of goodwill, on Sequential's 40th anniversary (this was also thanks to Roland's founder Ikutaro Kakehashi who convinced Yamaha that it would be the right thing to do) [1][2][3]
Strangely enough Yamaha has never released a software version of any of their synths. (there's S-YXG50 and the Montage one but I wouldn't really count those)
What really kills me about companies and maybe Yamaha is a little different, or rather drastically, is any time CEO's shift, or original founding CEO is swapped, the company culture changes too drastically. There's companies whose original culture I admired, and then the CEO shifts and its just meh, or worse.
Another thing they do right is build cheap instruments that are actually decent and have high build quality. It is quite remarkable how high quality their "beginner" and "intermediate" line saxophones are.
They are really well respected in professional music circles. I don't like their tenor saxes, but man they made some great altos and sopranos, including the mid tier ones.
As a complete audio outsider, my observations are:
1. Great news! VSTs seem to fill an important role in the audio-processing software world, and having them more open must be a good thing.
2. From the things they mention, the SDK seems way larger than I had imagined, but that is normal for (software) things, I guess. "This API also enables the scheduling of tasks on the main thread from any other thread." was not easy to unpack nor see the use of in what was (to me) an audio-generation-centered API.
3. The actual post seems to be somewhat mangled, I see both proper inline links and what looks like naked Markdown links, and also bolded words that also have double asterisks around them. Much confusing.
The basic threading model for plugins is the "main" and "audio" threads. The APIs specify which methods are allowed to be called concurrently from which thread.
There is also a state machine for the audio processing bits (for example you can guarantee that processing won't happen until after the plugin as been "activated" and won't go from a deactivated state to processing until a specific method is called - I'm simplifying significantly for the VST3 state machine).
The "main" thread is the literal main/UI thread of the application typically, or a sandboxed plugin host running in a separate process. You do your UI on this thread as well as handle most host events.
Plugins often want to do things on background threads, like stream audio from disk or do heavy work like preparing visualization without blocking the main UI thread (which also handles rendering and UI events - think like the JS event loop, it's bad to block it).
The threading model and state machine make it difficult to know where it's safe to spawn and join threads. You can do it in a number of places but you also have to be careful about lifetimes of those threads, most plugins do it as early as possible and then shut them down as late as possible.
The host also has to do a lot of the stuff on background threads and usually has its own thread pool. CLAP introduced an extension to hook into the host's thread pool so plugins don't have to spawn threads and no longer have to really care about the lifetime. VST3 is copying that feature.
When you see annotations on methods in these APIs about "main" vs "any" thread and "active" etc they're notes to developers on where it is safe to call the methods and any synchronization required (on both sides of the API).
If it sounds complicated that's because it is, but most of this is accidental complexity created by VST3.
Having only used VSTs but never even looked into how they're actually built - what does this now mean in simple terms? Did you need a specific closed source framework to build them or something like that? What has changed now?
At the same time Steinberg also open sourced their ASIO audio hardware interface standard but under GPL3. GPL2 here would have made more sense to me to align with the Linux kernel GPL2 only licensing. So why GPL3? Other commenters here have mentioned OBS, and OBS is "GPLv2 or later" so sure that works for them. Not being GPL 2 and missing on the Linux kernel just surprises me.
I have been using the nice cwASIO (https://github.com/s13n/cwASIO) re-implementation of the ASIO SDK, it's MIT licensed. https://github.com/s13n/cwASIO. It's nice there just to see something more up to date than the ancient ASIO SDK documentation. I would love to see the Steinberg ASIO SDK updated and improved, if you are listening Steinberg folks: nobody cares about the history of ASIO on Macs or Silicon Graphics Workstations, just dive in and get deep into the weeds of ASIO on Windows, and include lots more sample code, especially covering the ASIO device enumeration mess on Windows.
This is technical people at their finest! There couldn't be any news more important than this—or more anticipated by the community. For so many years people wished for this, and they announce it this low-key in a forum! This is so awesome. Thanks to Steinberg & YAMAHA, I guess so much good is to come out of it.
Wow, after all these years. This is a very Good Thing. You could get access to it before but you had to sign a very long agreement and it was always a PITA.
Steinberg is only going to benefit from this, I think.
I didn't realize VST3 was dual licensed but I don't know of any other way to download the VST3 libs other than the same Steinburg panel that, if memory serves, also required signing the agreement before you had access to any of them - ASIO included.
Why are we still centralizing open source on Microsoft's GitHub? Haven't we learned the risks of giving one corporation, especially one with a such a shady history, exclusive control over the world's open source activity?
Because they don't have exclusive control, unlike social media where you can't take your data and move it to another provider, you can just take your repo to whichever provider or self-hosted GitOps option you want.
The shift away from proprietary formats is long overdue.
As a composer and arranger working with different studios, I need multiple DAWs installed for compatibility. Every time I open my DAW or Gig Performer after a few days, it rescans all plugins. With around 800 installed, that happens across AU, VST, and VST3.
I hope Apple and Avid are holding meetings after this decision to help simplify the life of library/plugin makers. As an example AAX requires a complete mess to compile and test their plugins, and several AU plugins are just wrappers aroud VST that add another layer.
I really hope the next five years bring real standardization and smoother workflows.
It sucks to say but I completely stopped using DAWs and being into music production a few years ago when I completely switched to linux.
I have always felt the industry of digital audio processing and software to be overcommercialized and ripe for something akin to blender to change the game.
No more takedown notices for including legacy VST SDK in your github project? Wait, mine was 2.4, so I guess steinberg would still chase me down if I hadn't complied already.
I’d really like to see more plugins available in the LV2 format for my Ardour RT DAW.
Also, a quick recommendation : LSP (Linux Studio Plugins) an excellent collection of several open source plugins supporting CLAP, AU, LV2, VST2, VST3, LADSPA, and a standalone Jack versions https://lsp-plug.in/
46 comments
[ 274 ms ] story [ 104 ms ] threadAlso the license change could be caused by competition from CLAP which is very openly licensed.
[1] https://u-he.com/community/clap/
previous examples:
* Yamaha saved Korg by buying it when it was in financial trouble and giving it a cash injection, only to then sell it back to its previous owners once they had enough cash[1].
* Yamaha in the 80's had acquired Sequential (for those not familiar: Sequential Circuits is one of the most admired synthesizer makers). Many years later, Sequential's founder Dave Smith established a new company under a different name and in 2015 Yamaha decided to return the rights to use the Sequential brand to Smith, as a gesture of goodwill, on Sequential's 40th anniversary (this was also thanks to Roland's founder Ikutaro Kakehashi who convinced Yamaha that it would be the right thing to do) [1][2][3]
[1] https://www.soundonsound.com/music-business/history-korg-par...
[2] https://www.gearnews.com/american-giants-the-history-of-sequ...
[3] https://ra.co/news/42428
They are really well respected in professional music circles. I don't like their tenor saxes, but man they made some great altos and sopranos, including the mid tier ones.
1. Great news! VSTs seem to fill an important role in the audio-processing software world, and having them more open must be a good thing.
2. From the things they mention, the SDK seems way larger than I had imagined, but that is normal for (software) things, I guess. "This API also enables the scheduling of tasks on the main thread from any other thread." was not easy to unpack nor see the use of in what was (to me) an audio-generation-centered API.
3. The actual post seems to be somewhat mangled, I see both proper inline links and what looks like naked Markdown links, and also bolded words that also have double asterisks around them. Much confusing.
The basic threading model for plugins is the "main" and "audio" threads. The APIs specify which methods are allowed to be called concurrently from which thread.
There is also a state machine for the audio processing bits (for example you can guarantee that processing won't happen until after the plugin as been "activated" and won't go from a deactivated state to processing until a specific method is called - I'm simplifying significantly for the VST3 state machine).
The "main" thread is the literal main/UI thread of the application typically, or a sandboxed plugin host running in a separate process. You do your UI on this thread as well as handle most host events.
Plugins often want to do things on background threads, like stream audio from disk or do heavy work like preparing visualization without blocking the main UI thread (which also handles rendering and UI events - think like the JS event loop, it's bad to block it).
The threading model and state machine make it difficult to know where it's safe to spawn and join threads. You can do it in a number of places but you also have to be careful about lifetimes of those threads, most plugins do it as early as possible and then shut them down as late as possible.
The host also has to do a lot of the stuff on background threads and usually has its own thread pool. CLAP introduced an extension to hook into the host's thread pool so plugins don't have to spawn threads and no longer have to really care about the lifetime. VST3 is copying that feature.
When you see annotations on methods in these APIs about "main" vs "any" thread and "active" etc they're notes to developers on where it is safe to call the methods and any synchronization required (on both sides of the API).
If it sounds complicated that's because it is, but most of this is accidental complexity created by VST3.
At the same time Steinberg also open sourced their ASIO audio hardware interface standard but under GPL3. GPL2 here would have made more sense to me to align with the Linux kernel GPL2 only licensing. So why GPL3? Other commenters here have mentioned OBS, and OBS is "GPLv2 or later" so sure that works for them. Not being GPL 2 and missing on the Linux kernel just surprises me.
I have been using the nice cwASIO (https://github.com/s13n/cwASIO) re-implementation of the ASIO SDK, it's MIT licensed. https://github.com/s13n/cwASIO. It's nice there just to see something more up to date than the ancient ASIO SDK documentation. I would love to see the Steinberg ASIO SDK updated and improved, if you are listening Steinberg folks: nobody cares about the history of ASIO on Macs or Silicon Graphics Workstations, just dive in and get deep into the weeds of ASIO on Windows, and include lots more sample code, especially covering the ASIO device enumeration mess on Windows.
Steinberg is only going to benefit from this, I think.
That was with VST2, which is/was a proprietory format. VST3 has been dual licensed as GPLv3 + commercial for a long time now.
As a composer and arranger working with different studios, I need multiple DAWs installed for compatibility. Every time I open my DAW or Gig Performer after a few days, it rescans all plugins. With around 800 installed, that happens across AU, VST, and VST3.
I hope Apple and Avid are holding meetings after this decision to help simplify the life of library/plugin makers. As an example AAX requires a complete mess to compile and test their plugins, and several AU plugins are just wrappers aroud VST that add another layer.
I really hope the next five years bring real standardization and smoother workflows.
I have always felt the industry of digital audio processing and software to be overcommercialized and ripe for something akin to blender to change the game.
Audio programming is still low level and difficult, but I'm looking forward towards vibe coding some experiments with this.
I like to work privately on my open source projects, and then push it to a public repo after deleting my git history ( for the public repo anyway).