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]
On another note, it's very telling that companies that protect their "hey! we do this interesting thing, gonna buy?" character survives for much longer compared to companies which say "we can earn a ton of money if we do this".
The companies in the second lot does a lot of harm to their ecosystems to be able to continue existing.
Yamaha still document their products properly and provide very long driver support. I currently have a Yamaha product with USB from 1999 and there is still a maintained driver for it 26 years later, for Windows 11 and modern macOS versions.
Still they're a separate legal entity and their HQ, development, support, etc. are still located in Hamburg like they used to be since the early-mid 1980s when they released their MIDI sequencing software for Atari ST (Steinberg Twenty 4 I believe it was called?). I guess you could do worse than being bought by Yamaha, but I think this decision isn't related to it.
interesting stuff. I love Yamaha for audio stuff for sure, didn't know they owned Steinberg though.
Their speakers i think are lovely examples of their engineering quality. Great and honest sound, some of the best out there, and they are not super over-priced. Also ,they are super repairable. Had some really bad experiences with other brands which were, more expensive for a more biassed sound, had 'black gunk' over the PCBs as some kind of anti-repair mechanism. (overheats the boards too! ew!) and other crappy issues.
Cool to hear there's such a story behind the quality. Makes sense!
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.
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.
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
The direct result of the newer, open CLAP format being objectively better in every way. Steinberg has gone to great lengths to force adoption of the trash that is VST3 and retain it's stranglehold on the audio world, including but not limited to, takedowns of distributors, takedowns of VST2.4 SDKs, constant threats of legal action against independent VST2.4 developers forcing them to remove purchases from customers, and funding particular plugin frameworks & daw developers to slow CLAP adoption.
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.
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.
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
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.
Like 1 in 200 plugins supports CLAP, where 100% support VST, so if they can do it more easily and with less licensing burden, and even have some community contribution, that would be big.
It will be a while, if ever, before most plugins get the CLAP (pun intended).
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 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
VST plugins almost all have a GUI, thus the VST SDK has to support an entire cross-platform UI framework... This threading functionality is mostly about shipping input events/rendering updates back and forth to the main (UI) thread
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.
Audio is often processed on a separate thread than the UI. If memory serves (been a while) there's the UI portion and the audio engine portion of most VSTs, which can be booted together or independently. So threading is very important.
In principle this is a great thing -- but in reality this will only continue to exacerbate the monoculture of 1970s era musical metaphors in digital music production. The VST3 format is confined, much like MIDI 1.0, to provide extremely opinionated and limited instrument and sound processing designs. If AudioUnits were suddenly MIT licensed I would react very differently.
"opinionated and limited" in what way? I'm also curious to hear how AU differs appreciably from VST3, mostly at a conceptual level (as I'm already familiar with the low-level details of both APIs).
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/
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.
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 still get customers requesting that I distribute VST(2) builds. Some old DAWs and apps still can’t load VST3. Thus far it hasn’t been possible due to licensing restrictions with commercial plug-ins, imposed by Steinberg.
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.
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.
If someone at Yamaha is reading this, could you please release a firmware update for the Yamaha Reface CP so that the toy piano setting plays the hidden grand piano sound instead?
To get the hidden piano sound:
1. Turn Reface CP off.
2. Turn piano sound knob so it rests in between any two settings.
3. Turn Reface CP on.
The Reface CP is one of my favorite small keys piano instruments, and I got one specifically for the hidden piano sound, but it’s annoying to have to go through the above steps and I’m not experienced enough to mod the circuitry.
[+] [-] mastazi|4 months ago|reply
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
[+] [-] bayindirh|4 months ago|reply
It's worth a watch.
On another note, it's very telling that companies that protect their "hey! we do this interesting thing, gonna buy?" character survives for much longer compared to companies which say "we can earn a ton of money if we do this".
The companies in the second lot does a lot of harm to their ecosystems to be able to continue existing.
[+] [-] TazeTSchnitzel|4 months ago|reply
[+] [-] coldtea|4 months ago|reply
yamaha: sure, here you go
customer: great, thanks! lol, I also need a motorcycle. Do you know where I can buy a good one?
yamaha: you're not gonna believe this...
[+] [-] tannhaeuser|4 months ago|reply
Still they're a separate legal entity and their HQ, development, support, etc. are still located in Hamburg like they used to be since the early-mid 1980s when they released their MIDI sequencing software for Atari ST (Steinberg Twenty 4 I believe it was called?). I guess you could do worse than being bought by Yamaha, but I think this decision isn't related to it.
[+] [-] sim7c00|4 months ago|reply
Their speakers i think are lovely examples of their engineering quality. Great and honest sound, some of the best out there, and they are not super over-priced. Also ,they are super repairable. Had some really bad experiences with other brands which were, more expensive for a more biassed sound, had 'black gunk' over the PCBs as some kind of anti-repair mechanism. (overheats the boards too! ew!) and other crappy issues.
Cool to hear there's such a story behind the quality. Makes sense!
[+] [-] iainctduncan|4 months ago|reply
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.
[+] [-] unleaded|4 months ago|reply
[+] [-] seg_lol|4 months ago|reply
[+] [-] pantulis|4 months ago|reply
[+] [-] giancarlostoro|4 months ago|reply
[+] [-] unknown|4 months ago|reply
[deleted]
[+] [-] keyle|4 months ago|reply
[1] https://u-he.com/community/clap/
[+] [-] stuaxo|4 months ago|reply
[+] [-] artdigital|4 months ago|reply
[+] [-] dsp_person|4 months ago|reply
[+] [-] alterom|4 months ago|reply
[+] [-] jcelerier|4 months ago|reply
[+] [-] Polarity|4 months ago|reply
[+] [-] pier25|4 months ago|reply
[+] [-] oybng|4 months ago|reply
[+] [-] postit|4 months ago|reply
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.
[+] [-] sureglymop|4 months ago|reply
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.
[+] [-] pmkary|4 months ago|reply
[+] [-] unknown|4 months ago|reply
[deleted]
[+] [-] p4bl0|4 months ago|reply
[+] [-] sagacity|4 months ago|reply
[+] [-] coldtea|4 months ago|reply
It will be a while, if ever, before most plugins get the CLAP (pun intended).
[+] [-] unwind|4 months ago|reply
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.
[+] [-] swiftcoder|4 months ago|reply
VST plugins almost all have a GUI, thus the VST SDK has to support an entire cross-platform UI framework... This threading functionality is mostly about shipping input events/rendering updates back and forth to the main (UI) thread
[+] [-] duped|4 months ago|reply
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.
[+] [-] junon|4 months ago|reply
[+] [-] odiroot|4 months ago|reply
[+] [-] waffletower|4 months ago|reply
[+] [-] wrl|4 months ago|reply
[+] [-] codedokode|4 months ago|reply
Also the license change could be caused by competition from CLAP which is very openly licensed.
[+] [-] lateralux|4 months ago|reply
[+] [-] dramm|4 months ago|reply
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.
[+] [-] junon|4 months ago|reply
Steinberg is only going to benefit from this, I think.
[+] [-] spacechild1|4 months ago|reply
That was with VST2, which is/was a proprietory format. VST3 has been dual licensed as GPLv3 + commercial for a long time now.
[+] [-] AaronAPU|4 months ago|reply
I wonder if that will change as well..
[+] [-] pottering|4 months ago|reply
https://steinbergmedia.github.io/vst3_dev_portal/pages/VST+3...
https://steinbergmedia.github.io/vst3_dev_portal/pages/VST+3...
It is the same, there is only the pre-2018 licenses.
(But a few hosts that avoided VST3 due to licensing may implement it now due to this change.)
[+] [-] WhereIsTheTruth|4 months ago|reply
[+] [-] dorkypunk|4 months ago|reply
[+] [-] brulard|4 months ago|reply
[+] [-] hypertexthero|4 months ago|reply
To get the hidden piano sound:
1. Turn Reface CP off.
2. Turn piano sound knob so it rests in between any two settings.
3. Turn Reface CP on.
The Reface CP is one of my favorite small keys piano instruments, and I got one specifically for the hidden piano sound, but it’s annoying to have to go through the above steps and I’m not experienced enough to mod the circuitry.
[+] [-] unknown|4 months ago|reply
[deleted]
[+] [-] radarsat1|4 months ago|reply