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.
I've had some impressive customer service from Yamaha concerning decades old saxophones that they have zero prospect of generating revenue from in the future, for an unrelated (musical) data point.
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.
Completely separate companies, both called Yamaha. One was spun off from the other, but I don't think there was ever a time when the same company sold both. (Basically, the musical instrument company was redirected to making war materiel during WWII. After the war, they didn't want to just throw away all of their new industrial capacity so they spun off a company to make use of all their new equipment and expertise and then went back to making instruments.)
I love Yamaha Motor using the tuning forks as their logo. It's a proper beautiful old-timey logo (well, from 1967, apparently, but anyway) and it's just so weird seeing them on a motorcycle.
Apparently they also make network switches. I guess it is in support of their computerized audio equipment. but I was a bit surprised when they showed up in a search result.
They have the technical capability to design one, but on the surface it is enough outside their core product line that I wonder if it is a oem rebadge.
I don't think Yamaha Motor is producing any large trucks. They do a lot of things but mostly motorcycles, atv, boat engine, even car engines but not the whole car.
Also, you should note that Yamaha Corporation, the musical instrument maker and Yamaha Motor are now 2 distinct independent companies, even if were originally part of the same group.
Customer: "So, I need some huge IGBTs for an electric train motor, I need a 44-tonne excavator to lift the train, I need a new stereo to listen to while I fix it, and I need an, uhm, 'personal massager' to relax afterwards"
Sales guy: "Here's our catalogue, page 40, page 32, page 108, and page 7. Let me know what colours you want."
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.
All the commercial ones I've bought in the past year or so do, and ever since I think JUCE 7 there have been good libraries for open source projects that want to add the format.
I think there's still a lot of bad feeling about the fact that there are many VST2 plugins that are open source but nonetheless illegal (or at least tortious) to build.
I see more and more brands not only adopting CLAP but also offering Linux versions of their plugins. The adoption is slow but that's expected with a relatively new format but it certainly grows.
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
Clap doesn't allow describing plugin in a manifest (like VST3 and LV2 do). This allows to scan for plugins faster.
Also, CLAP uses 3 or 4 methods to represent MIDI data (MIDI1, MIDI1 + MPE, MIDI2, CLAP events). This requires to write several converters when implementing a host.
But, CLAP is much simpler and doesn't use COM-like system (VST3 resembles a Windows COM library with endless interfaces and GUIDs).
Also, VST3 interfaces in SDK are described as C++ classes with virtual functions (example: [1]), and I wonder how do they achieve portability, if the layout for such classes (vtables) is not standardized and may differ across compilers.
You would have thought they learned from their mistakes implementing VST2, but they doubled down going even further basing VST3 on the Windows Component Object Model. I guess it was a decision to avoid reinventing the wheel, but you can quickly realize it is a very bad model for real time audio plugins and audio host support. The API just exploded in complexity, and testing was a nightmare. In contrast you can tell the U-He developers have all the experience from the trenches.
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
Funnily enough, that video talks about the pain of implementing a VST3 host at around the 25 minute mark. "If you're planning on doing it, set aside a lot of time."
i have my own vst3 host. it's not really that difficult.
the real problem is that theres a lot of plugins that do some random thing that wont work becasue it's not standard.
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).
Most plugins don't use these APIs directly, they rely on wrappers like JUCE. Once JUCE supports CLAP the plugins will follow. That should happen in the next year.
The bigger problem are hosts. While Apple and Avid will probably never support CLAP, everyone but Ableton does. They move slower than the rest of the industry (taking a decade or so to implement VST3). Which is odd because CLAP is significantly easier to use from both the host and plugin side.
That said, you can wrap a clap plugin as a vst3 or AU today. It's probably the lowest friction way to do it to be honest.
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
There is no single UI framework in VST. The plugin API only has interfaces for creating/destroying/resizing a GUI window. You are not required to use VSTGUI.
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.
Yeah, I realized that once I finished writing my comment, that it might be about communicating with the UI since UI toolkits are usually not thread-safe enough. Thanks.
Readit News
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
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.
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...
https://www.yamaha.com/en/about/history/logo/
https://usa.yamaha.com/products/proaudio/network_switches/in...
They have the technical capability to design one, but on the surface it is enough outside their core product line that I wonder if it is a oem rebadge.
Also, you should note that Yamaha Corporation, the musical instrument maker and Yamaha Motor are now 2 distinct independent companies, even if were originally part of the same group.
Customer: "So, I need some huge IGBTs for an electric train motor, I need a 44-tonne excavator to lift the train, I need a new stereo to listen to while I fix it, and I need an, uhm, 'personal massager' to relax afterwards"
Sales guy: "Here's our catalogue, page 40, page 32, page 108, and page 7. Let me know what colours you want."
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.
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!
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.
Deleted Comment
[1] https://u-he.com/community/clap/
u-he's stuff (Diva, Repro, Zebra) has CLAP builds.
As another comment mentioned, I guess FabFilter plugs support CLAP now?
It is niche but I am watching it closely as I would love to get off of Windows or MacOS and CLAP plugins often have linux support.
https://cleveraudio.org/hosts-and-plug-ins/
I think there's still a lot of bad feeling about the fact that there are many VST2 plugins that are open source but nonetheless illegal (or at least tortious) to build.
They becoming popular on the back of Diva, and Hans Zimmer using Zebra (he's very fulsome in his praise whenever mentioning u-he in interviews).
Also, CLAP uses 3 or 4 methods to represent MIDI data (MIDI1, MIDI1 + MPE, MIDI2, CLAP events). This requires to write several converters when implementing a host.
But, CLAP is much simpler and doesn't use COM-like system (VST3 resembles a Windows COM library with endless interfaces and GUIDs).
Also, VST3 interfaces in SDK are described as C++ classes with virtual functions (example: [1]), and I wonder how do they achieve portability, if the layout for such classes (vtables) is not standardized and may differ across compilers.
[1] https://github.com/steinbergmedia/vst3_pluginterfaces/blob/3...
Deleted Comment
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.
Deleted Comment
If you're planning to do that. Set aside a lot of time.....
It will be a while, if ever, before most plugins get the CLAP (pun intended).
The bigger problem are hosts. While Apple and Avid will probably never support CLAP, everyone but Ableton does. They move slower than the rest of the industry (taking a decade or so to implement VST3). Which is odd because CLAP is significantly easier to use from both the host and plugin side.
That said, you can wrap a clap plugin as a vst3 or AU today. It's probably the lowest friction way to do it to be honest.
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.
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.