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.
Japanese companies don't give you a good service because of future revenue prospects.
They give a good service because they respect the thing they built and the person who cares for it. They want their products to live and bring joy to people who guards and cares for them.
This is a completely different and much deeper philosophy.
This is not limited to Japanese companies though. A Lamy representative told me that the factory in Germany restored an out of production fountain pen to mint condition, for free.
Want a bit for your early 80s Mercedes? Your local dealer probably has it, or knows where to get it.
Want a bit for your early 50s Mercedes? Your local dealer knows a guy in Stuttgart who will send it over.
Want a bit for your early 30s Mercedes? Your local dealer knows a guy in Stuttgart who knows a guy who will *just go and make you one*, albeit it will be priced accordingly.
In the early 80s, a friend restored a 1936 Mercedes-Benz 170V Saloon that he found in pieces in the attic of an old downtown Seattle body shop. It took five pickup truck loads to get the entire car to his shop and about three years to completely restore it to original condition. He had almost every part except for the steel wheel that was for the spare tire, the instrument dial backgrounds, and the rubber window surround moldings.
Despite combing the Earth for that fifth wheel for the spare, he was never able to find one but, since the spare tire was kept underneath a trimmed cover on the back of the car, it wasn't missed. The instrument dials he faked by carefully photographing, and printing on photographic paper, a set of dial faces.
Those rubber window moldings?
He was able to have a well-connected German friend contact Mercedes in Germany where they responded by breaking out the original molds and producing two complete sets for the car.
The year after the car was complete, it won a local Mercedes-Benz of America concours show by 4/100ths of one point over a Gullwing that had just gone through a $200,000 restoration.
I think both them and BMW have all the tools to make any part they used on production models. Not sure exactly how far back either catalog goes, but from what I've heard it is total for even 60s & 70s and maybe 50s models. Of course the way out of date stuff will cost but they could make something for you if your really want it.
Dealing with BMW is hilarious because you will end up speaking to some guy either looks about 14 or like God's older brother, and he will say either "Ja so this part, I will show you how you take the beer can and you cut a piece like this, oder so, and it will fit over this and it is ready, ja? Ausgezeichnett, ja?" or he will say "Ja so this part, it is a special order from Munich and it will be four thousand euros but we will have it tomorrow" and the customer being German will just pay it and pick the car up after work tomorrow, and that's it, end of the story, done.
Or the customer will be Austrian and there is nothing for it but assassinating archdukes and bloody warfare over a 1.50EUR gasket.
Both Yamaha and Roland keep a long back catalogue of reasonably priced parts for at least their mid-range pianos and up as well. I should check Korg too I guess.
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.
i’ll add a third anecdote i to the ether to say that i steinburg ur mark ii from a million years ago still works as well as it ever did, including regular driver updates. in no means meant to discredit your experience, ymmv as always.
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.)
Not sure about the meaning of your asterisk, but the Nokian Tyres corporation is not related to Nokia the telecoms co, other than being founded in the same town.
Nokia did manufacture rubber boots though, before they spun off the footwear division in 1990 and went all in on electronics.
This changed in 1988 with the formation of an LLC, in 1995 they went public and in 2003 shares still held by the parent company were sold off to Bridgestone.
>I had no idea you've never heard of it. Thanks for keeping us informed.
I see.
In that case, you'll appreciate the fact that the Three Musketeers chocolate bar bears no relationship to Alexander Dumas, the author of the famed book series featuring D'Artagnan and three musketeers.
You might also be interested to learn that Zenit launch vehicles are not made by the organization that produces Zenit optics and cameras.
Most crucially, Lucky grocery store chain in California turns out to be completely different from the Korean Lucky chemical products and electronics conglomerate (known as "Lucky GoldStar" after merging its chem and electronics wings, and, currently, "LG").
I didn't realize when I was a kid that the Yamaha music company came first.
I remember being confused when looking at high end saxophones that one was made by an old French company (that made sense, France makes many fine luxury goods including instruments) and the other was (in my mind) made by a motorcycle company. How could a motorcycle company possibly have compiled the expertise to make high end musical instruments when most musical instrument companies were chasing the low end of the market at the time?
But Yamaha music (1887) was started only 2 years after Selmer (1885). They got their start making reed organs. Reed organs (1) are technical, (2) make sound with reeds, and (3) are luxury items. So their expertise in sax (a reed instrument) and synthesizers (technical keyboard instruments) makes a ton of sense.
It even says in your link "The former motorcycle division was established in 1955 as Yamaha Motor Co., Ltd., which started as an affiliated company but has been spun-off as its own independent company. "
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.
They claim that they're developing routers since 1995 and they're used widely in domestic Japan (SME and SOHO).
Looks like switches came in 2011 and there's some secret sauce which makes them autoconfigure each-other to reduce networking setup.
It might not be a standard OEM stuff.
Citing the page:
> Yamaha entered the router business in 1995, and has grown to hold a significant share of Japan’s small to medium enterprise and SOHO network market. Yamaha gigabit L2 switches that could be linked to Yamaha routers/firewalls were introduced in 2011, with features that significantly reduced the network setup, maintenance, and management workload.
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.
They are independent yes, but originally the motor company was an affiliate spin-off. They do have an agreement and share the same logo, and Yamaha Corporation has some shares in the Motor one tho.
They actually made at least one model, of which only 3 prototypes were built before the project was cancelled due to the economic situation at the time: the Yamaha OX99-11 supercar was using a detuned version of their formula one v12 engine when they switched to v10. I guess they had built to many of them?
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.
If you have the source code and use JUCE then yes, you can convert the plugin to VST3. But if you don't use a framework then you need to port the code manually.
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.
I like my old ACE, but people with better ears than me say that the sound engine is not as good as some other U-He synths but it was more in my price range and I wanted something good enough but without DRM. U-He was (is?) one of the few makers of audio software that did not rely on some online registration or USB dongles (plus Linux support as a bonus).
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.
>Also, CLAP uses 3 or 4 methods to represent MIDI data (MIDI1, MIDI1 + MPE, MIDI2, CLAP events)
Contrast to VST3 which doesn't support MIDI at all, unless you count cresting thousands of dummy parameters hardcoded to MIDI controller numbers "support."
VST3 uses proprietary events for things like note on/off and note expressions. As for MIDI controllers, the host is supposed to convert them to parameter changes.
This makes sense if you want to map a controller to a plugin parameter in a DAW. However, if you want to write a "MIDI effect", which transforms incoming MIDI data for controllers, it would be difficult.
Also it is interesting that VST3 has an event for note expression, and separate event for polyphonic pressure although it can be considered a note expression.
As I understand it is better because it gives more freedom in routing parameter values. The parameter values might come not only from a MIDI controller knob directly, but from an automation curve, or from other plugin output, or from an automation track output. For example, you might combine 2 automation curves through a multiplication plugin and route the output to a plugin's parameter input.
Or you could have an automation curve that produces a sine wave, and have a MIDI knob to modulate its amplitude, and send the result to an LPF "cutoff frequency" input, so that you can control amount of modulation with a knob.
So VST3 (and CLAP) treat each parameter as an additional plugin input, which can be routed arbitrarily.
If a plugin would instead have a single MIDI input and extract controller changes from a MIDI stream, then the scenario above would be more difficult to implement (you would need to convert an output of multiplication plugin into a sequence of MIDI controller changes and combine it with other MIDI events).
Am I missing something here? Never developed a single plugin.
The first is that VST3 does not exist in a vacuum. Plugin developers need to ship AU (and previously VST2 concurrently with VST3) plugins. MIDI still is the basic abstraction used by higher level wrappers for sending events to plugins, so in practice, all VST3 events get converted to MIDI anyway (for the majority of plugins).
The second thing is that parameter values are special. You do not actually want the modulation features you are talking about to touch the parameter value, you want them to be used as modulation sources on top of the parameter value. Most synths for example treat MIDI CC and pitch bend as modulation sources to the voice pitch or other parameters (programmable by the user), and not direct controls of parameters. Keep in mind that parameters are typically serialized and saved for preset values.
The third thing is that parameters not in practice allowed to be dynamic. So if you want to use a MIDI controller as a modulation source, you need a dedicated parameter for it. You cannot dynamically add and remove it based on user input.
As an example:
> Or you could have an automation curve that produces a sine wave, and have a MIDI knob to modulate its amplitude, and send the result to an LPF "cutoff frequency" input,
This is not possible in VST3, in any host I'm aware of. You cannot output parameters from one plugin to route to another until 3.8, and I highly doubt anyone will support this.
VST3 is less flexible and more surprising in how it handles midi which is why historically, VST3 plugins have very poor MIDI support.
I think you can find something similar in a modular synth: you can have an envelope generator that generates control voltage, and connect it to a filter cutoff frequency input.
I don't care much how it is made in other DAWs, I just tried to design a routing system for a DAW on a paper. I needed a concept that would be simple yet powerful. So I thought that we can define 3 types of data - audio data, MIDI data and automation (parameter) data. And every plugin may have inputs/outputs of these types. So if a plugin has 20 parameters, we can count them as 20 inputs. And we can connect inputs and outputs however we want (as long as the types match). Of course, we also have 3 types of clips - audio, MIDI and automation curve clips. And obviously we can process these data with plugins - so we can take a MIDI clip, connect it to a plugin that generates envelopes for incoming MIDI notes, and connect its output to a cutoff frequency of a filter. Why not?
Technically it is possible to process parameter data, we just have to deal with converting data between different formats - some plugins might have "control voltage" inputs/outputs, other allow changing parameters sample- or block-precise points. And here VST3, which has a defined model for parameter interpolation, is easier to deal with than plugin formats that do not define exact interpolation formula.
By the way now I noted a serious weakness in my model - it doesn't support per-note parameters/controllers - all parameters are global in my concept. Guess I need to think more.
Your point about modulating parameters is valid, however I am not sure if it is better to implement modulation in a host and have full control over it (what do we do if a user moves a knob when the automation is being played) or have every plugin developer to implement it themselves (like in CLAP which supports parameter modulation).
> This is not possible in VST3,
I think it is possible - the plugin gets a sequence of parameter changes from the host and doesn't care where they come from. As I remember, plugins may also have output parameters, so it is possible to process parameter data using plugins.
So your paper design is most similar in spirit to CLAP. I would say that the actual audio/event processing bits are the "easy" part of the API.
> And here VST3, which has a defined model for parameter interpolation, is easier to deal with than plugin formats that do not define exact interpolation formula.
So I'll just reiterate that this is not true for either plugin or host developers and that's not a minority opinion. The parameter value queue abstraction is harder to implement on both sides of the API, has worse performance, and doesn't provide much in benefit over sending a sparse list of time-stamped events and delegating smoothing to the plugin.
> As I remember, plugins may also have output parameters, so it is possible to process parameter data using plugins.
The host forwards those output parameters back to that plugin's editor, not to other plugins. You use this as a hack to support metering, although in practice since this is a VST3 quirk, few people do it. Until 3.8.0 which added the IMidiLearn2 interface there was no way to annotate MIDI mappings for output parameters, which caused hosts to swallow MIDI messages even if they should be forwarded to all plugins. I doubt that the new interface will be implemented consistently by hosts, and now there's a problem where old plugins may do the wrong thing in new versions of hosts that expect plugins to be updated (this is catastrophic behavior for audio plugins - you never want a version update to change how they behave, because it breaks old sessions). There's also no good way to consistently send what are effectively automation clips out of plugins, since the plugin does not have a view into the sequencer.
And most importantly - plugins aren't aware of other plugins. If one plugin outputs an parameter change it is meaningless to another plugin. Maybe if both plugins implement IMidiMapping2 the host can translate the output parameter change into a MIDI event and then into another parameter change. Sounds a lot stupider than just sending discrete MIDI events.
Essentially, the design of parameters in VST3 is fragile and bad.
You are right though that many DAWs do not allow to route and process parameter data (control voltages) - I notice that some plugins implement this internally, especially synths, so you can draw curves and process them inside a plugin - but I think it would be better if you didn't need every plugin developer to add a curve editor and modulators.
> Clap doesn't allow describing plugin in a manifest (like VST3 and LV2 do). This allows to scan for plugins faster.
VST3 only recently gained the `moduleinfo.json` functionality and support is still materialising. Besides, hosts generally do a much better job about only scanning new plugins or ones that have changed, and hosts like Bitwig even do the scanning in the background. The manifest approach is cool, but in the end, plugin DLLs just shouldn't be doing any heavy lifting until they actually need to create an instance anyway.
> 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.
I've not done the host-side work, but the plugin-side work isn't too difficult. It's the same data, just represented differently. Disclaimer: I don't support MIDI2 yet, but I support the other 3.
On the other side, VST3 has some very strange design decisions that have led me to a lot of frustration.
Having separate parameter queues for sample-accurate automation requires plugins to treat their parameters in a very specific way (basically, you need audio-rate buffers for your parameter values that are as long as the maximum host block) in order to be written efficiently. Otherwise plugins basically have to "flatten" those queues into a single queue and handle them like MIDI events, or alternately just not handle intra-block parameter values at all. JUCE still doesn't handle these events at all, which leads to situations where a VST2 build of a JUCE plugin will actually handle automation better than the VST3 build (assuming the host is splitting blocks for better automation resolution, which all modern hosts do).
duped's comment about needing to create "dummy" parameters which get mapped to MIDI CCs is spot-on as well. JUCE does this. 2048 additional parameters (128 controllers * 16 channels) just to receive CCs. At least JUCE handles those parameters sample-accurately!
There's other issues too but I've lost track. At one point I sent a PR to Steinberg fixing a bug where their VST3 validator (!!!) was performing invalid (according to their own documentation) state transitions on plugins under test. It took me weeks to get the VST3 implementation in my plugin framework to a shippable state, and I still find more API and host bugs than I ever hit in VST2. VST3 is an absolute sprawl of API "design" and there are footguns in more places than there should be.
On the contrary, CLAP support took me around 2 days, 3 if we're being pedantic. The CLAP API isn't without its share of warts, but it's succinct and well-documented. There's a few little warts (the UI extension in particular should be more clear about when and how a plugin is supposed to actually open a window) but these are surmountable, and anecdotally I have only had to report one (maybe two) host bugs so far.
Again, disclaimer: I was involved in the early CLAP design efforts (largely the parameter extension) and am therefore biased, but if CLAP sucked I wouldn't shy away from saying it.
> Having separate parameter queues for sample-accurate automation requires plugins to treat their parameters in a very specific way (basically, you need audio-rate buffers for your parameter values that are as long as the maximum host block) in order to be written efficiently.
Oh I forgot about parameters. In VST3, the parameter changes use linear interpolation. So the DAW can predict how the plugin would interpret parameter value between changes and use this to create the best piece-wise linear approximation for automation curve (not merely sampling the curve every N samples uniformly which is not perfect).
CLAP has no defined interpolation method, and every plugin would interpolate the values in its own, unique and unpredictable way (and if you don't interpolate, there might be clicks). It is more difficult for a host to create an approximation for an automation curve. So with CLAP "sample-precise" might be not actually sample-precise.
I didn't find anything about interpolation in the spec, but it mentions interpolation for note expressions [1]:
> A plugin may make a choice to smooth note expression streams.
Also, I thought that maybe CLAP should have used the same event for parameters and note expessions? Aren't they very similar?
> duped's comment about needing to create "dummy" parameters which get mapped to MIDI CCs is spot-on as well. JUCE does this. 2048 additional parameters (128 controllers * 16 channels) just to receive CCs. At least JUCE handles those parameters sample-accurately!
What is the purpose of this? Why does plugin (unless it is a MIDI effect) need values for all controllers? Also, MIDI2 has more than 128 controllers anyway so this is a poor solution.
> Oh I forgot about parameters. In VST3, the parameter changes use linear interpolation. So the DAW can predict how the plugin would interpret parameter value between changes and use this to create the best piece-wise linear approximation for automation curve (not merely sampling the curve every N samples uniformly which is not perfect).
Can you link to any code anywhere that actually correctly uses the VST3 linear interpolation code (other than the "again_sampleaccurate" sample in the VST3 SDK)? AU also supports "ramped" sample-accurate parameter events, but I am not aware of any hosts or plugins that use this functionality.
> CLAP has no defined interpolation method, and every plugin would interpolate the values in its own, unique and unpredictable way (and if you don't interpolate, there might be clicks). It is more difficult for a host to create an approximation for an automation curve. So with CLAP "sample-precise" might be not actually sample-precise.
Every plugin does already interpolate values on its own. It's how plugin authors address zipper noise. VST3 would require plugin authors to sometimes use their own smoothing and sometimes use the lerped values. Again, I'm not aware of any plugins that actually implement the linear interpolated method. I think Melda? It certainly requires both building directly on the VST3 SDK and also using the sample-accurate helpers (which only showed up in 2021 with 3.7.3).
Anyway, I maintain that this is a bad design. Plugins are already smoothing their parameters (usually with 1 pole smoothing filters) and switching to this whole interpolated sample accurate VST3 system requires a pretty serious restructuring.
Personally, I would have loved having a parameter event flag in CLAP indicating whether a plugin should smooth a parameter change or snap immediately to it (for better automation sync). Got overruled, oh well.
> What is the purpose of this? Why does plugin (unless it is a MIDI effect) need values for all controllers? Also, MIDI2 has more than 128 controllers anyway so this is a poor solution.
Steinberg has been saying exactly this since 2004 when VST3 was first released. Time and time again, plugin developers say that they do need them. For what? Couldn't tell you, honestly. In my case, I would have to migrate a synth plugin from MPE to also be able to use the VST3 note expressions system, and I absolutely cannot be bothered - note expressions look like a nightmare.
And this is the chief problem with VST3. The benefits are either dubious or poorly communicated, and the work required to implement these interfaces is absurd. Again – 3 days to implement CLAP vs 3 weeks to implement VST3 and I'm still finding VST3 host bugs routinely.
I don't think GCC has a special case for handling COM classes. However, I found that GCC uses "Itanium CXX ABI" on Linux which specifies vtable layout which accidentally might match the layout of COM classes. However, it is not guaranteered (for example, by C++ standards) that other compilers use the same layout.
The ABI isn't covered by C++ standards, it's target and architecture dependent. For the purposes of this discussion that ABI is stable for C++ vtables on the targets and architectures that VST3 supports.
If a compiler and linker don't follow those ABIs then it would also be close to useless for compiling or linking against shared libraries. So in the wild, all useful compilers do target the same ABIs.
gcc in mingw on windows is the odd duck, but most production software does not support it anyway.
Not really, VST3's COM-like API just uses virtual methods, they don't guarantee layout to the same degree actual COM does with compiler support. They simply rely on the platform ABI being standardized enough.
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.
> COM is just 3 predefined calls in the virtual table.
COM can be as simple as that implementation side, at least if your platforms vtable ABI matches COM's perfectly, but it also allows far more complicated implementations where every implemented interface queried will allocate a new distinct object, etc.
I.E. even if you know for sure that the object is implemented in c++, and your platforms' vtable ABI matches COM's perfectly, and you know exactly what interfaces the object you have implements, you cannot legally use dynamic_cast, as there is no requirement that one class inherits from both interfaces. The conceptual "COM object" could instead be implemented as one class per interface, each likely containing a pointer to some shared data class.
This is also why you need to do the ref counting with respect to each distinct interface, since while it is legal from an implementation side to just share one ref count for it all, that is in no way required.
Note that VST3 doesn't implement the COM vtable layout, their COM-like FUnknown really is just 3 virtual methods and a bunch of GUIDs. They rely on the platform's C++ ABI not breaking.
You're right that QueryInterface can return a different object, but that doesn't make it significantly more complicated, assuming you're not managing the ref-counts manually.
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
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.
I know it isn't nowhere near in adoption NOW. I meant it shows there is room for another format and AU is a good example of how another format can make inroads.
AU support grew because Logic Pro only loads AU, Logic userbase is a attractive enough market for plugin devs.
On the other hand, there is not a single DAW that only loads CLAP.
That's the same problem Steinberg faced with VST3 years ago, every host/DAW/plugin supported VST2 (including Cubase), there was no reason for devs to switch to VST3.
Steinberg forced the issue killing the VST2 licenses, any new plugin and host had only access to the VST3 license, even then devs resisted, only recently Steinberg announced future Cubase/Nuendo versions won't support VST2 anymore (plugin devs may hate Steinberg, but they won't simply leave Cubase/Nuendo users without support, they are not to blame for Steinberg's stupidity).
CLAP can't force the issue the same way Steinberg did with VST3, there is no CLAP-only DAW either.
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.
There's that, and then there's the explicit design decision that the two are very cleanly separated as it's somewhat common in more professional environments to run the audio portion on another machine entirely, and configure it on the main desktop.
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).
For instance VST3 does not support many to one, and only awkwardly supports two to one -- via second-class "side-chaining" -- sound processing architectures. But the need for such possibility may not be clear to those who only know the primary one-to-one audio flow architecture ubiquitous in digital audio workstation ("DAWWWWWWW") designs. VST3 neatly fits into this architecture. In 2025 I don't think more of this is particularly innovative. In contrast, the AudioUnit spec is open ended and has an internal graph audio flow design that can readily facilitate other signal processing architectures. If you don't want to think outside the "DAW", you don't have to, but some of us musicians do.
> For instance VST3 does not support many to one, and only awkwardly supports two to one -- via second-class "side-chaining" -- sound processing architectures
This is a limitation of your host and plugins and not of VST3, plugins can declare arbitrarily many input/output busses for audio and events for many-to-many connections. It's just that in practice, hosts don't like this, and JUCE has a busted interface for it.
This is really interesting – AU's notion of having separate input and output "elements" (buses, more or less) is one of the worst parts of the whole API.
I understand why historically these design decisions were made, but it's not like they really enable any functionality that the other APIs don't. It's just that since the host can call `Render` more than once per sample block (ideally the host would call it once per sample block per element, but there's nothing saying the host can't call it redundantly), there's additional bookkeeping that plugins have to do surrounding the `AudioTimeStamp`. And for what? There's nothing AU can do that the other formats can't.
If a plugin has multiple fully independent buses, the model mostly works, but if there's any interdependence then things get even more complicated. Say you have two separate stereo elements that don't have any routing between them, but there's MIDI input or sample-accurate parameter changes for the given block. Now you have to keep those events around until the host has moved on to the next block, which means the plugin has to maintain even more internal buffering. This sort of lifetime ambiguity was one of the worst parts of VST2. In VST2, how long does MIDI input last? "Until the next call to `process()`." In AUv2, how long do MIDI input data or parameter change events last? "All of the render calls of the next timestamp, but then not the timestamp after that." Great, thanks.
Modern plugins, upon receiving a `Render` for a new timestamp, will just render all of their elements at the same time, but they'll internally buffer all the outputs and then just copy the buffers out per-element-render call. So, it reduces down to the same thing that other APIs do, just with more pageantry.
And yet, plugin instances having to manage their own input connection types is somehow even worse. Again, I understand why it was done this way – allowing plugins to "pull" their own inputs lets an audio graph basically run itself with very little effort from the host – it can just call `Render` on the final node of the chain, and all of the inputs come along for free.
It's a compelling value proposition, but unfortunately it fully prevents any sort of graph-level multithreading. Modern hosts do all sorts of graph theory to determine which parts of the graph can be executed in parallel, and this means that the host has to be in charge of determining which plugins to render and when. Even Logic does this now. The "pull model" of an AU instance directly calling `Render` on its input connections is relic of the past.
Anyway. VST3, CLAP, even VST2 support multiple input and output buses (hell, one of my plugins has multiple output buses for "main out", "only transients", and "everything other than a transient") – it's just a question of host support and how they're broken out. Ironically, Logic is one of the clunkiest implementations of multi-out I've seen (Bitwig is far and away the best).
I am unfamiliar with the differences between these two at all, as someone who uses audio plugins but does not develop with them. What are the main differences and why is OP claiming that there are far better methods of doing so?
The short answer is that there really aren't. All extant audio plugin APIs/formats are basically ways of getting audio data into and out of a `process()` (sometimes called `Render`) function which gets called by the host application whenever it needs more audio from the plugin.
Every API has its own pageantry not just around the details of calling `process()`, but also exposing and manipulating things like parameters, bus configuration, state management, MIDI/note i/o, etc. There are differences in all of these (sometimes big differences), but there aren't any real crazy outliers.
At the end of the day, a plugin instance is a sort of "object", right? And the host calls methods on it. How the calls look varies considerably:
VST2 prescribes a big `switch()` statement in a "dispatcher" function, with different constants for the "command" (or "method", more or less). VST3 uses COM-like vtables and `QueryInterface`. CLAP uses a mechanism where a plugin (or host) is queried for an "extension" (identified by a string), and the query returns a const pointer to a vtable (or NULL if the host/plugin doesn't support the extension). AudioUnits has some spandrels of the old mac "Component Manager", including a `Lookup` method for mapping constants to function pointers (kind of similar to VST2 except it returns a function rather than dispatching to it directly), and then AU also has a "property" system with getters and setters for things like bus configuration, saving/loading state, parameter metadata, etc.
I'm not sure why OP is claiming that AU is somehow unopinionated or less limited. It doesn't support any particular extensibility that the other formats don't too.
Historically, there was an API translation layer that VST2 plugins used (called Symbiosis), but these days the vast majority of plugin devs use a framework like JUCE which has multiple different "client-side" API implementations (of VST2, and VST3, and etc) that all wrap around JUCE's native class hierarchy.
There's a few other frameworks floating around (Dplug for writing in D, a few others in C++), but JUCE is far and away the most common.
Me three would like to know. I'm producer/mixer who favors AU over VST3 plugins. Not for any opinionated reason. Merely because my experience is that they're slightly less error prone in my DAW.
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 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.
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.
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.
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've never dabbled in audio programming but am both a tech-minded musician and developer. Care to share any starter links, orgs, platforms, tools, or even your own work to point me in the right direction?
( rly, feel free to plug your own work :D )
At the same time it's too little too late. I still won't forget how they killed the VST2 SDK and came after people who hosted copies. This was terrible for people who tried to build existing open source VST2 plugins. It was even worse for people who wanted to write a VST2 host, but couldn't get a license anymore. This was at a time when VST3 support was far from universal and many plugins didn't ship VST3 versions. (Not to mention all the existing plugins that never will.)
I mean, these "SDKs" are just goddamn header files! *) They shouldn't have been proprietory in the first place. Now, if they also re-release the VST2 SDK under the MIT license and apologize for their crass behavior, then I will actually give them credit.
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?
You had to accept some license terms before you could download the VST SDK. When linux audio started to get "serious" 20 years ago, it was a commonly discussed pain point.
Concretely, it made distributing OSS VST plugins a pain. Especially for Linux which generally will want to build their packages.
Note that his was the VST2 era. VST3 was commercial license or GPL 3, which was an improvement, but only slightly, because it excluded open-source software released under the GPL 2, and also MIT/BSD/whatever-licensed software couldn't use it (without effectively turning the whole software into GPL-licensed software).
Since I never agreed to the VST3 SDK terms, which required you to give up your license to VST2, does this mean I can finally make VST3 plugins without losing the ability to publish VST2?
You'd have to use this version (not sure if they back-licensed old versions) but MIT would mean you wouldn't have to agree to that draconian licensing.
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]
[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
Yamaha is an old company found on very different ethos compared to others. Their history is interesting, too: https://www.youtube.com/watch?v=y6t5F3cb810
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.
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.
Japanese companies don't give you a good service because of future revenue prospects.
They give a good service because they respect the thing they built and the person who cares for it. They want their products to live and bring joy to people who guards and cares for them.
This is a completely different and much deeper philosophy.
This is not limited to Japanese companies though. A Lamy representative told me that the factory in Germany restored an out of production fountain pen to mint condition, for free.
Want a bit for your early 80s Mercedes? Your local dealer probably has it, or knows where to get it.
Want a bit for your early 50s Mercedes? Your local dealer knows a guy in Stuttgart who will send it over.
Want a bit for your early 30s Mercedes? Your local dealer knows a guy in Stuttgart who knows a guy who will *just go and make you one*, albeit it will be priced accordingly.
In the early 80s, a friend restored a 1936 Mercedes-Benz 170V Saloon that he found in pieces in the attic of an old downtown Seattle body shop. It took five pickup truck loads to get the entire car to his shop and about three years to completely restore it to original condition. He had almost every part except for the steel wheel that was for the spare tire, the instrument dial backgrounds, and the rubber window surround moldings.
Despite combing the Earth for that fifth wheel for the spare, he was never able to find one but, since the spare tire was kept underneath a trimmed cover on the back of the car, it wasn't missed. The instrument dials he faked by carefully photographing, and printing on photographic paper, a set of dial faces.
Those rubber window moldings?
He was able to have a well-connected German friend contact Mercedes in Germany where they responded by breaking out the original molds and producing two complete sets for the car.
The year after the car was complete, it won a local Mercedes-Benz of America concours show by 4/100ths of one point over a Gullwing that had just gone through a $200,000 restoration.
I think both them and BMW have all the tools to make any part they used on production models. Not sure exactly how far back either catalog goes, but from what I've heard it is total for even 60s & 70s and maybe 50s models. Of course the way out of date stuff will cost but they could make something for you if your really want it.
Dealing with BMW is hilarious because you will end up speaking to some guy either looks about 14 or like God's older brother, and he will say either "Ja so this part, I will show you how you take the beer can and you cut a piece like this, oder so, and it will fit over this and it is ready, ja? Ausgezeichnett, ja?" or he will say "Ja so this part, it is a special order from Munich and it will be four thousand euros but we will have it tomorrow" and the customer being German will just pay it and pick the car up after work tomorrow, and that's it, end of the story, done.
Or the customer will be Austrian and there is nothing for it but assassinating archdukes and bloody warfare over a 1.50EUR gasket.
BMW’s online catalogue indeed reaches back to the 60s: https://www.bmwgroup-classic.com/en/services/spare-parts/bmw...
It is not true for all Japanese companies, unfortunately. Some would sell their grandmother. Growth quarter after quarter is what matters
Both Yamaha and Roland keep a long back catalogue of reasonably priced parts for at least their mid-range pianos and up as well. I should check Korg too I guess.
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.
I wouldn't depend on them to do this for all their products esp software. I can think of two of the top of my head that they dropped support.
i’ll add a third anecdote i to the ether to say that i steinburg ur mark ii from a million years ago still works as well as it ever did, including regular driver updates. in no means meant to discredit your experience, ymmv as always.
customer: hello, I want to buy a piano please
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...
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.)
Although the Yamaha that makes music and audio products is the same Yamaha that makes golf clubs (https://global.golf.yamaha.com/en/) and industrial equipment (https://www.yamahafinetech.co.jp/en/).
The OG Yamaha produced a motorcycle in 1954, the YA-1. That success then led to the spin off.
(fun fact: the motorcycle Triumph and the undergarment Triumph are two entirely different companies that just happen to share the same name)
A motorcycle named Norton Commander also exists, and Nokia* sold winter bicycle tires with studs on them so they would grip better on ice and snow.
Not sure about the meaning of your asterisk, but the Nokian Tyres corporation is not related to Nokia the telecoms co, other than being founded in the same town.
Nokia did manufacture rubber boots though, before they spun off the footwear division in 1990 and went all in on electronics.
The company's history page says they were part of the merger in 1967 that created "Big Nokia": https://company.nokiantyres.com/about-us/history/#:~:text=19...
This changed in 1988 with the formation of an LLC, in 1995 they went public and in 2003 shares still held by the parent company were sold off to Bridgestone.
Nokian studded tires for bicycles are (were?) the best! Rode many-many kilometers at winter with them!
Triumph is also a garment brand? Never heard of it.
I had no idea you've never heard of it. Thanks for keeping us informed.
>I had no idea you've never heard of it. Thanks for keeping us informed.
I see.
In that case, you'll appreciate the fact that the Three Musketeers chocolate bar bears no relationship to Alexander Dumas, the author of the famed book series featuring D'Artagnan and three musketeers.
You might also be interested to learn that Zenit launch vehicles are not made by the organization that produces Zenit optics and cameras.
Most crucially, Lucky grocery store chain in California turns out to be completely different from the Korean Lucky chemical products and electronics conglomerate (known as "Lucky GoldStar" after merging its chem and electronics wings, and, currently, "LG").
The more you know!
It’s also a Wonder Dog, a Canadian power trio not featuring Neal Peart, and a moment when we shouldn’t evacuate the Death Star.
> Wonder Dog
I think you meant Insult Comic Dog.
I guess we were too good at Triumphing…
I didn't realize when I was a kid that the Yamaha music company came first.
I remember being confused when looking at high end saxophones that one was made by an old French company (that made sense, France makes many fine luxury goods including instruments) and the other was (in my mind) made by a motorcycle company. How could a motorcycle company possibly have compiled the expertise to make high end musical instruments when most musical instrument companies were chasing the low end of the market at the time?
But Yamaha music (1887) was started only 2 years after Selmer (1885). They got their start making reed organs. Reed organs (1) are technical, (2) make sound with reeds, and (3) are luxury items. So their expertise in sax (a reed instrument) and synthesizers (technical keyboard instruments) makes a ton of sense.
Day Start proekror proom
Same company
They may have “different legal entities” but it’s the same.
https://en.wikipedia.org/wiki/Yamaha_Corporation
Yeah, that's one of them. Here's the other:
https://en.wikipedia.org/wiki/Yamaha_Motor_Company
It even says in your link "The former motorcycle division was established in 1955 as Yamaha Motor Co., Ltd., which started as an affiliated company but has been spun-off as its own independent company. "
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.
https://www.yamaha.com/en/about/history/logo/
Just pretend it is the thing that hold the front wheel.
Coincidentally also called a fork/forks :)
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.
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.
They claim that they're developing routers since 1995 and they're used widely in domestic Japan (SME and SOHO).
Looks like switches came in 2011 and there's some secret sauce which makes them autoconfigure each-other to reduce networking setup.
It might not be a standard OEM stuff.
Citing the page:
> Yamaha entered the router business in 1995, and has grown to hold a significant share of Japan’s small to medium enterprise and SOHO network market. Yamaha gigabit L2 switches that could be linked to Yamaha routers/firewalls were introduced in 2011, with features that significantly reduced the network setup, maintenance, and management workload.
Huh, thanks for sharing. Funny to see the switches in the same color scheme as some of their receivers.
They make Dante licenced products.
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.
They are independent yes, but originally the motor company was an affiliate spin-off. They do have an agreement and share the same logo, and Yamaha Corporation has some shares in the Motor one tho.
a former keiretsu?
Former, current, reformed keiretsu?
> but not the whole car
They actually made at least one model, of which only 3 prototypes were built before the project was cancelled due to the economic situation at the time: the Yamaha OX99-11 supercar was using a detuned version of their formula one v12 engine when they switched to v10. I guess they had built to many of them?
See also Hitachi ;-)
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."
Wait till you find out about Mitsubishi.
I remember being bewildered their diversity as a teenager, and then even more so when I found out that MUFG actually backed my bank at the time.
"We build things that make noise."
Had no idea it was bought by Yamaha.
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)
Great recap!
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.
Congrats for making it but it feels like being pushed to do it since CLAP was brought forward quite successfully [1]
[1] https://u-he.com/community/clap/
Very useful for all the existing plugins though, especially if any want to become open source.
I do a fair bit of music and have never seen a CLAP plugin in the wild
A lot of open-source plugins include CLAP builds.
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 use FabFilter plugins all the time.
what kind of music? I'm looking to connect with other musicians and just so happen to also be a techie on here :)
how has CLAP adoption been? do the popular plugins out there generally provide a CLAP version nowadays?
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.
Hopefully this provides a path for those VST2 plugins.
No. VST2 has nothing in common with VST3 despite similar name.
Why? In Juce isn't that a matter of choosing multiple build target?
If you have the source code and use JUCE then yes, you can convert the plugin to VST3. But if you don't use a framework then you need to port the code manually.
Notionally yes but the idea of keeping the DSP and the container logic separate is relatively new and lots of projects didn't do it.
(Actually the idea is very old and how most LADSPA plugins were made but some time in the mid oughts everybody forgot about it.)
If you're using JUCE and not using any of the VST2 features removed in VST3.
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.
There is a list of software with support here https://clapdb.tech/
Wow, didn't realize u-he grew so big. I remember them from Zebra days.
They aren't big - but they are bigger than when it was just Urs and a couple of guys turning out plugins.
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).
I guess big as in widely impactful.
Making a new plugin standard that is gaining wide adoption is big in my head.
They make a lot of great virtual instruments nowadays. Diva being a big one.
I like my old ACE, but people with better ears than me say that the sound engine is not as good as some other U-He synths but it was more in my price range and I wanted something good enough but without DRM. U-He was (is?) one of the few makers of audio software that did not rely on some online registration or USB dongles (plus Linux support as a bonus).
clap is way better
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.
[1] https://github.com/steinbergmedia/vst3_pluginterfaces/blob/3...
>Also, CLAP uses 3 or 4 methods to represent MIDI data (MIDI1, MIDI1 + MPE, MIDI2, CLAP events)
Contrast to VST3 which doesn't support MIDI at all, unless you count cresting thousands of dummy parameters hardcoded to MIDI controller numbers "support."
VST3 uses proprietary events for things like note on/off and note expressions. As for MIDI controllers, the host is supposed to convert them to parameter changes.
This makes sense if you want to map a controller to a plugin parameter in a DAW. However, if you want to write a "MIDI effect", which transforms incoming MIDI data for controllers, it would be difficult.
Also it is interesting that VST3 has an event for note expression, and separate event for polyphonic pressure although it can be considered a note expression.
> As for MIDI controllers, the host is supposed to convert them to parameter changes
And nearly everyone except Steinberg considers this to be a mistake. MIDI messages (CCs, pitch bend, and so on) are _not_ parameters.
As I understand it is better because it gives more freedom in routing parameter values. The parameter values might come not only from a MIDI controller knob directly, but from an automation curve, or from other plugin output, or from an automation track output. For example, you might combine 2 automation curves through a multiplication plugin and route the output to a plugin's parameter input.
Or you could have an automation curve that produces a sine wave, and have a MIDI knob to modulate its amplitude, and send the result to an LPF "cutoff frequency" input, so that you can control amount of modulation with a knob.
So VST3 (and CLAP) treat each parameter as an additional plugin input, which can be routed arbitrarily.
If a plugin would instead have a single MIDI input and extract controller changes from a MIDI stream, then the scenario above would be more difficult to implement (you would need to convert an output of multiplication plugin into a sequence of MIDI controller changes and combine it with other MIDI events).
Am I missing something here? Never developed a single plugin.
So there's a couple of problems here.
The first is that VST3 does not exist in a vacuum. Plugin developers need to ship AU (and previously VST2 concurrently with VST3) plugins. MIDI still is the basic abstraction used by higher level wrappers for sending events to plugins, so in practice, all VST3 events get converted to MIDI anyway (for the majority of plugins).
The second thing is that parameter values are special. You do not actually want the modulation features you are talking about to touch the parameter value, you want them to be used as modulation sources on top of the parameter value. Most synths for example treat MIDI CC and pitch bend as modulation sources to the voice pitch or other parameters (programmable by the user), and not direct controls of parameters. Keep in mind that parameters are typically serialized and saved for preset values.
The third thing is that parameters not in practice allowed to be dynamic. So if you want to use a MIDI controller as a modulation source, you need a dedicated parameter for it. You cannot dynamically add and remove it based on user input.
As an example:
> Or you could have an automation curve that produces a sine wave, and have a MIDI knob to modulate its amplitude, and send the result to an LPF "cutoff frequency" input,
This is not possible in VST3, in any host I'm aware of. You cannot output parameters from one plugin to route to another until 3.8, and I highly doubt anyone will support this.
VST3 is less flexible and more surprising in how it handles midi which is why historically, VST3 plugins have very poor MIDI support.
I think you can find something similar in a modular synth: you can have an envelope generator that generates control voltage, and connect it to a filter cutoff frequency input.
I don't care much how it is made in other DAWs, I just tried to design a routing system for a DAW on a paper. I needed a concept that would be simple yet powerful. So I thought that we can define 3 types of data - audio data, MIDI data and automation (parameter) data. And every plugin may have inputs/outputs of these types. So if a plugin has 20 parameters, we can count them as 20 inputs. And we can connect inputs and outputs however we want (as long as the types match). Of course, we also have 3 types of clips - audio, MIDI and automation curve clips. And obviously we can process these data with plugins - so we can take a MIDI clip, connect it to a plugin that generates envelopes for incoming MIDI notes, and connect its output to a cutoff frequency of a filter. Why not?
Technically it is possible to process parameter data, we just have to deal with converting data between different formats - some plugins might have "control voltage" inputs/outputs, other allow changing parameters sample- or block-precise points. And here VST3, which has a defined model for parameter interpolation, is easier to deal with than plugin formats that do not define exact interpolation formula.
By the way now I noted a serious weakness in my model - it doesn't support per-note parameters/controllers - all parameters are global in my concept. Guess I need to think more.
Your point about modulating parameters is valid, however I am not sure if it is better to implement modulation in a host and have full control over it (what do we do if a user moves a knob when the automation is being played) or have every plugin developer to implement it themselves (like in CLAP which supports parameter modulation).
> This is not possible in VST3,
I think it is possible - the plugin gets a sequence of parameter changes from the host and doesn't care where they come from. As I remember, plugins may also have output parameters, so it is possible to process parameter data using plugins.
So your paper design is most similar in spirit to CLAP. I would say that the actual audio/event processing bits are the "easy" part of the API.
> And here VST3, which has a defined model for parameter interpolation, is easier to deal with than plugin formats that do not define exact interpolation formula.
So I'll just reiterate that this is not true for either plugin or host developers and that's not a minority opinion. The parameter value queue abstraction is harder to implement on both sides of the API, has worse performance, and doesn't provide much in benefit over sending a sparse list of time-stamped events and delegating smoothing to the plugin.
> As I remember, plugins may also have output parameters, so it is possible to process parameter data using plugins.
The host forwards those output parameters back to that plugin's editor, not to other plugins. You use this as a hack to support metering, although in practice since this is a VST3 quirk, few people do it. Until 3.8.0 which added the IMidiLearn2 interface there was no way to annotate MIDI mappings for output parameters, which caused hosts to swallow MIDI messages even if they should be forwarded to all plugins. I doubt that the new interface will be implemented consistently by hosts, and now there's a problem where old plugins may do the wrong thing in new versions of hosts that expect plugins to be updated (this is catastrophic behavior for audio plugins - you never want a version update to change how they behave, because it breaks old sessions). There's also no good way to consistently send what are effectively automation clips out of plugins, since the plugin does not have a view into the sequencer.
And most importantly - plugins aren't aware of other plugins. If one plugin outputs an parameter change it is meaningless to another plugin. Maybe if both plugins implement IMidiMapping2 the host can translate the output parameter change into a MIDI event and then into another parameter change. Sounds a lot stupider than just sending discrete MIDI events.
Essentially, the design of parameters in VST3 is fragile and bad.
You are right though that many DAWs do not allow to route and process parameter data (control voltages) - I notice that some plugins implement this internally, especially synths, so you can draw curves and process them inside a plugin - but I think it would be better if you didn't need every plugin developer to add a curve editor and modulators.
> Clap doesn't allow describing plugin in a manifest (like VST3 and LV2 do). This allows to scan for plugins faster.
VST3 only recently gained the `moduleinfo.json` functionality and support is still materialising. Besides, hosts generally do a much better job about only scanning new plugins or ones that have changed, and hosts like Bitwig even do the scanning in the background. The manifest approach is cool, but in the end, plugin DLLs just shouldn't be doing any heavy lifting until they actually need to create an instance anyway.
> 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.
I've not done the host-side work, but the plugin-side work isn't too difficult. It's the same data, just represented differently. Disclaimer: I don't support MIDI2 yet, but I support the other 3.
On the other side, VST3 has some very strange design decisions that have led me to a lot of frustration.
Having separate parameter queues for sample-accurate automation requires plugins to treat their parameters in a very specific way (basically, you need audio-rate buffers for your parameter values that are as long as the maximum host block) in order to be written efficiently. Otherwise plugins basically have to "flatten" those queues into a single queue and handle them like MIDI events, or alternately just not handle intra-block parameter values at all. JUCE still doesn't handle these events at all, which leads to situations where a VST2 build of a JUCE plugin will actually handle automation better than the VST3 build (assuming the host is splitting blocks for better automation resolution, which all modern hosts do).
duped's comment about needing to create "dummy" parameters which get mapped to MIDI CCs is spot-on as well. JUCE does this. 2048 additional parameters (128 controllers * 16 channels) just to receive CCs. At least JUCE handles those parameters sample-accurately!
There's other issues too but I've lost track. At one point I sent a PR to Steinberg fixing a bug where their VST3 validator (!!!) was performing invalid (according to their own documentation) state transitions on plugins under test. It took me weeks to get the VST3 implementation in my plugin framework to a shippable state, and I still find more API and host bugs than I ever hit in VST2. VST3 is an absolute sprawl of API "design" and there are footguns in more places than there should be.
On the contrary, CLAP support took me around 2 days, 3 if we're being pedantic. The CLAP API isn't without its share of warts, but it's succinct and well-documented. There's a few little warts (the UI extension in particular should be more clear about when and how a plugin is supposed to actually open a window) but these are surmountable, and anecdotally I have only had to report one (maybe two) host bugs so far.
Again, disclaimer: I was involved in the early CLAP design efforts (largely the parameter extension) and am therefore biased, but if CLAP sucked I wouldn't shy away from saying it.
> Having separate parameter queues for sample-accurate automation requires plugins to treat their parameters in a very specific way (basically, you need audio-rate buffers for your parameter values that are as long as the maximum host block) in order to be written efficiently.
Oh I forgot about parameters. In VST3, the parameter changes use linear interpolation. So the DAW can predict how the plugin would interpret parameter value between changes and use this to create the best piece-wise linear approximation for automation curve (not merely sampling the curve every N samples uniformly which is not perfect).
CLAP has no defined interpolation method, and every plugin would interpolate the values in its own, unique and unpredictable way (and if you don't interpolate, there might be clicks). It is more difficult for a host to create an approximation for an automation curve. So with CLAP "sample-precise" might be not actually sample-precise.
I didn't find anything about interpolation in the spec, but it mentions interpolation for note expressions [1]:
> A plugin may make a choice to smooth note expression streams.
Also, I thought that maybe CLAP should have used the same event for parameters and note expessions? Aren't they very similar?
> duped's comment about needing to create "dummy" parameters which get mapped to MIDI CCs is spot-on as well. JUCE does this. 2048 additional parameters (128 controllers * 16 channels) just to receive CCs. At least JUCE handles those parameters sample-accurately!
What is the purpose of this? Why does plugin (unless it is a MIDI effect) need values for all controllers? Also, MIDI2 has more than 128 controllers anyway so this is a poor solution.
[1] https://github.com/free-audio/clap/blob/main/include/clap/ev...
> Oh I forgot about parameters. In VST3, the parameter changes use linear interpolation. So the DAW can predict how the plugin would interpret parameter value between changes and use this to create the best piece-wise linear approximation for automation curve (not merely sampling the curve every N samples uniformly which is not perfect).
Can you link to any code anywhere that actually correctly uses the VST3 linear interpolation code (other than the "again_sampleaccurate" sample in the VST3 SDK)? AU also supports "ramped" sample-accurate parameter events, but I am not aware of any hosts or plugins that use this functionality.
> CLAP has no defined interpolation method, and every plugin would interpolate the values in its own, unique and unpredictable way (and if you don't interpolate, there might be clicks). It is more difficult for a host to create an approximation for an automation curve. So with CLAP "sample-precise" might be not actually sample-precise.
Every plugin does already interpolate values on its own. It's how plugin authors address zipper noise. VST3 would require plugin authors to sometimes use their own smoothing and sometimes use the lerped values. Again, I'm not aware of any plugins that actually implement the linear interpolated method. I think Melda? It certainly requires both building directly on the VST3 SDK and also using the sample-accurate helpers (which only showed up in 2021 with 3.7.3).
Anyway, I maintain that this is a bad design. Plugins are already smoothing their parameters (usually with 1 pole smoothing filters) and switching to this whole interpolated sample accurate VST3 system requires a pretty serious restructuring.
Personally, I would have loved having a parameter event flag in CLAP indicating whether a plugin should smooth a parameter change or snap immediately to it (for better automation sync). Got overruled, oh well.
> What is the purpose of this? Why does plugin (unless it is a MIDI effect) need values for all controllers? Also, MIDI2 has more than 128 controllers anyway so this is a poor solution.
Steinberg has been saying exactly this since 2004 when VST3 was first released. Time and time again, plugin developers say that they do need them. For what? Couldn't tell you, honestly. In my case, I would have to migrate a synth plugin from MPE to also be able to use the VST3 note expressions system, and I absolutely cannot be bothered - note expressions look like a nightmare.
And this is the chief problem with VST3. The benefits are either dubious or poorly communicated, and the work required to implement these interfaces is absurd. Again – 3 days to implement CLAP vs 3 weeks to implement VST3 and I'm still finding VST3 host bugs routinely.
> 2048 additional parameters (128 controllers * 16 channels) just to receive CCs.
It's worth mentioning that it's 2 x 16 x 16,384 in MIDI 2, + 128 x 16 MIDI1 because you gotta support both.
But to quote Steinberg devs, "plugins shouldn't handle MIDI CC at all"
they are com classes. the vtable layout for them is specified.
I don't think GCC has a special case for handling COM classes. However, I found that GCC uses "Itanium CXX ABI" on Linux which specifies vtable layout which accidentally might match the layout of COM classes. However, it is not guaranteered (for example, by C++ standards) that other compilers use the same layout.
The ABI is stable everywhere VST3s are used. It has to be or nothing would work.
Everything would work except for VST3, if written according to standards.
The ABI isn't covered by C++ standards, it's target and architecture dependent. For the purposes of this discussion that ABI is stable for C++ vtables on the targets and architectures that VST3 supports.
If a compiler and linker don't follow those ABIs then it would also be close to useless for compiling or linking against shared libraries. So in the wild, all useful compilers do target the same ABIs.
gcc in mingw on windows is the odd duck, but most production software does not support it anyway.
> If a compiler and linker don't follow those ABIs then it would also be close to useless for compiling or linking against shared libraries.
I guess in C++ you are not supposed to link libraries produced by different compilers? Maybe you should use C-compatible interfaces in this case?
You are, you can, and people do. Sure you should use C interfaces, that's what CLAP does, and it's easier to understand as a result.
The C standard similarly does not specify an ABI.
Not really, VST3's COM-like API just uses virtual methods, they don't guarantee layout to the same degree actual COM does with compiler support. They simply rely on the platform ABI being standardized enough.
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.
> it is a very bad model for real time audio plugins and audio host support
COM is just 3 predefined calls in the virtual table. CLAP gives you a bunch of pointers to functions, which is similar.
> COM is just 3 predefined calls in the virtual table.
COM can be as simple as that implementation side, at least if your platforms vtable ABI matches COM's perfectly, but it also allows far more complicated implementations where every implemented interface queried will allocate a new distinct object, etc.
I.E. even if you know for sure that the object is implemented in c++, and your platforms' vtable ABI matches COM's perfectly, and you know exactly what interfaces the object you have implements, you cannot legally use dynamic_cast, as there is no requirement that one class inherits from both interfaces. The conceptual "COM object" could instead be implemented as one class per interface, each likely containing a pointer to some shared data class.
This is also why you need to do the ref counting with respect to each distinct interface, since while it is legal from an implementation side to just share one ref count for it all, that is in no way required.
Note that VST3 doesn't implement the COM vtable layout, their COM-like FUnknown really is just 3 virtual methods and a bunch of GUIDs. They rely on the platform's C++ ABI not breaking.
You're right that QueryInterface can return a different object, but that doesn't make it significantly more complicated, assuming you're not managing the ref-counts manually.
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
Can you give us the highlights of why it was easier to use?
Maybe Steinberg is getting ready to add CLAP to their software?
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.
IIRC that's also what is said in the video.
try implementing the same without VST3 technology.
If you're planning to do that. Set aside a lot of time.....
I just hope they don't try to sneak in Google Analytics again.
I’m keeping a very close eye on audacity 4 mostly to make sure they don’t try something again lol
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.
Some cool ones do support CLAP, such as:
While they may not do everything, to me as a novice, those two do cover a lot of ground for free.CLAP might be similar to AU in plugin support which is pretty common too.
CLAP is nowhere near close to AU in adoption.
Almost all VST plugins have an AU version (like 80%-90% or so, and 99% of the major ones).
Almost no VST plugins have a CLAP version (like 1%-5%, and that's charitable).
I know it isn't nowhere near in adoption NOW. I meant it shows there is room for another format and AU is a good example of how another format can make inroads.
AU support grew because Logic Pro only loads AU, Logic userbase is a attractive enough market for plugin devs.
On the other hand, there is not a single DAW that only loads CLAP.
That's the same problem Steinberg faced with VST3 years ago, every host/DAW/plugin supported VST2 (including Cubase), there was no reason for devs to switch to VST3.
Steinberg forced the issue killing the VST2 licenses, any new plugin and host had only access to the VST3 license, even then devs resisted, only recently Steinberg announced future Cubase/Nuendo versions won't support VST2 anymore (plugin devs may hate Steinberg, but they won't simply leave Cubase/Nuendo users without support, they are not to blame for Steinberg's stupidity).
CLAP can't force the issue the same way Steinberg did with VST3, there is no CLAP-only DAW either.
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.
For context, the variation in UI between VSTs is pretty large and tend to be very creative, much like UI in games.
For better or worse, frequently worse
Like traveling back in time before UX was a word
Correct, it just hands you native handles. What you do with them is up to you.
JUCE is a popular UI framework (at least it was 10 years ago). But I've seen people put electron apps somehow into a VST.
Oh man, this is really starting to look like a plague.
And yet here we are discussing the value of using C++ vs other languages for real time audio processing.
Some background is needed for the thread API
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.
There's that, and then there's the explicit design decision that the two are very cleanly separated as it's somewhat common in more professional environments to run the audio portion on another machine entirely, and configure it on the main desktop.
Most probably a response to CLAP gaining popularity. But they buried a lede with Wayland support. This puts VST3 ahead of CLAP in that regard.
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).
For instance VST3 does not support many to one, and only awkwardly supports two to one -- via second-class "side-chaining" -- sound processing architectures. But the need for such possibility may not be clear to those who only know the primary one-to-one audio flow architecture ubiquitous in digital audio workstation ("DAWWWWWWW") designs. VST3 neatly fits into this architecture. In 2025 I don't think more of this is particularly innovative. In contrast, the AudioUnit spec is open ended and has an internal graph audio flow design that can readily facilitate other signal processing architectures. If you don't want to think outside the "DAW", you don't have to, but some of us musicians do.
> For instance VST3 does not support many to one, and only awkwardly supports two to one -- via second-class "side-chaining" -- sound processing architectures
This is a limitation of your host and plugins and not of VST3, plugins can declare arbitrarily many input/output busses for audio and events for many-to-many connections. It's just that in practice, hosts don't like this, and JUCE has a busted interface for it.
This is really interesting – AU's notion of having separate input and output "elements" (buses, more or less) is one of the worst parts of the whole API.
I understand why historically these design decisions were made, but it's not like they really enable any functionality that the other APIs don't. It's just that since the host can call `Render` more than once per sample block (ideally the host would call it once per sample block per element, but there's nothing saying the host can't call it redundantly), there's additional bookkeeping that plugins have to do surrounding the `AudioTimeStamp`. And for what? There's nothing AU can do that the other formats can't.
If a plugin has multiple fully independent buses, the model mostly works, but if there's any interdependence then things get even more complicated. Say you have two separate stereo elements that don't have any routing between them, but there's MIDI input or sample-accurate parameter changes for the given block. Now you have to keep those events around until the host has moved on to the next block, which means the plugin has to maintain even more internal buffering. This sort of lifetime ambiguity was one of the worst parts of VST2. In VST2, how long does MIDI input last? "Until the next call to `process()`." In AUv2, how long do MIDI input data or parameter change events last? "All of the render calls of the next timestamp, but then not the timestamp after that." Great, thanks.
Modern plugins, upon receiving a `Render` for a new timestamp, will just render all of their elements at the same time, but they'll internally buffer all the outputs and then just copy the buffers out per-element-render call. So, it reduces down to the same thing that other APIs do, just with more pageantry.
And yet, plugin instances having to manage their own input connection types is somehow even worse. Again, I understand why it was done this way – allowing plugins to "pull" their own inputs lets an audio graph basically run itself with very little effort from the host – it can just call `Render` on the final node of the chain, and all of the inputs come along for free.
It's a compelling value proposition, but unfortunately it fully prevents any sort of graph-level multithreading. Modern hosts do all sorts of graph theory to determine which parts of the graph can be executed in parallel, and this means that the host has to be in charge of determining which plugins to render and when. Even Logic does this now. The "pull model" of an AU instance directly calling `Render` on its input connections is relic of the past.
Anyway. VST3, CLAP, even VST2 support multiple input and output buses (hell, one of my plugins has multiple output buses for "main out", "only transients", and "everything other than a transient") – it's just a question of host support and how they're broken out. Ironically, Logic is one of the clunkiest implementations of multi-out I've seen (Bitwig is far and away the best).
I am unfamiliar with the differences between these two at all, as someone who uses audio plugins but does not develop with them. What are the main differences and why is OP claiming that there are far better methods of doing so?
The short answer is that there really aren't. All extant audio plugin APIs/formats are basically ways of getting audio data into and out of a `process()` (sometimes called `Render`) function which gets called by the host application whenever it needs more audio from the plugin.
Every API has its own pageantry not just around the details of calling `process()`, but also exposing and manipulating things like parameters, bus configuration, state management, MIDI/note i/o, etc. There are differences in all of these (sometimes big differences), but there aren't any real crazy outliers.
At the end of the day, a plugin instance is a sort of "object", right? And the host calls methods on it. How the calls look varies considerably:
VST2 prescribes a big `switch()` statement in a "dispatcher" function, with different constants for the "command" (or "method", more or less). VST3 uses COM-like vtables and `QueryInterface`. CLAP uses a mechanism where a plugin (or host) is queried for an "extension" (identified by a string), and the query returns a const pointer to a vtable (or NULL if the host/plugin doesn't support the extension). AudioUnits has some spandrels of the old mac "Component Manager", including a `Lookup` method for mapping constants to function pointers (kind of similar to VST2 except it returns a function rather than dispatching to it directly), and then AU also has a "property" system with getters and setters for things like bus configuration, saving/loading state, parameter metadata, etc.
I'm not sure why OP is claiming that AU is somehow unopinionated or less limited. It doesn't support any particular extensibility that the other formats don't too.
Is there some software to convert VST3 to AU? Or do you develop both separately?
Someone else said
> Almost all VST plugins have an AU version (like 80%-90% or so, and 99% of the major ones).
Which I noticed as well, I wondered if that required a large time investment to support both or there's some API translation layers available.
Historically, there was an API translation layer that VST2 plugins used (called Symbiosis), but these days the vast majority of plugin devs use a framework like JUCE which has multiple different "client-side" API implementations (of VST2, and VST3, and etc) that all wrap around JUCE's native class hierarchy.
There's a few other frameworks floating around (Dplug for writing in D, a few others in C++), but JUCE is far and away the most common.
Me three would like to know. I'm producer/mixer who favors AU over VST3 plugins. Not for any opinionated reason. Merely because my experience is that they're slightly less error prone in my DAW.
Before VST3 code was under GPL3 license and GPL2 software (like LMMS) couldn't use it.
Also the license change could be caused by competition from CLAP which is very openly licensed.
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/
Well done Steinberg/Yamaha.
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.
> You could get access to it before but you had to sign a very long agreement and it was always a PITA.
That was with VST2, which is/was a proprietory format. VST3 has been dual licensed as GPLv3 + commercial for a long time now.
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.
The VST3 SDK has been available on GitHub since 2017. I think that's when they introduced the GPLv3 option. See https://github.com/steinbergmedia/vst3sdk
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.
I wonder if that will change as well..
Nope, the wording in the SDK explicitly says, and I quote "VST 2 API source code is NOT part of this VST 3 license!"
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.)
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.
Not only can you take it with you, every developer already has a local copy of the entire repository.
The real value IMHO of github is the issue tracker and the visual diff/display of PR changes.
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.
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.
Oh wow, finally! They should have done this 20 years ago but this is awesome news.
This is fantastic.
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).
I've never dabbled in audio programming but am both a tech-minded musician and developer. Care to share any starter links, orgs, platforms, tools, or even your own work to point me in the right direction? ( rly, feel free to plug your own work :D )
This is great news!
At the same time it's too little too late. I still won't forget how they killed the VST2 SDK and came after people who hosted copies. This was terrible for people who tried to build existing open source VST2 plugins. It was even worse for people who wanted to write a VST2 host, but couldn't get a license anymore. This was at a time when VST3 support was far from universal and many plugins didn't ship VST3 versions. (Not to mention all the existing plugins that never will.)
I mean, these "SDKs" are just goddamn header files! *) They shouldn't have been proprietory in the first place. Now, if they also re-release the VST2 SDK under the MIT license and apologize for their crass behavior, then I will actually give them credit.
/rant off
*) Yes, the VST3 SDK is huge, but the only things you really need are the headers in https://github.com/steinbergmedia/vst3_pluginterfaces/tree/m.... The VST2 SDK only consistet of two header files (aeffect.h and aeffectx.h)
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?
You had to accept some license terms before you could download the VST SDK. When linux audio started to get "serious" 20 years ago, it was a commonly discussed pain point.
Concretely, it made distributing OSS VST plugins a pain. Especially for Linux which generally will want to build their packages.
Note that his was the VST2 era. VST3 was commercial license or GPL 3, which was an improvement, but only slightly, because it excluded open-source software released under the GPL 2, and also MIT/BSD/whatever-licensed software couldn't use it (without effectively turning the whole software into GPL-licensed software).
Since I never agreed to the VST3 SDK terms, which required you to give up your license to VST2, does this mean I can finally make VST3 plugins without losing the ability to publish VST2?
You'd have to use this version (not sure if they back-licensed old versions) but MIT would mean you wouldn't have to agree to that draconian licensing.
Wow!! What a huge and wonderful change. Hats off, Steinberg.
Can anyone fluent with all this tell me whether that will make the usage of Arturia [zillion of] plugins trivial in Linux distros?
CLAP supports polyphonic modulation
This simplifies a ton of things.
[dead]
[flagged]
no, his name is John Cena!
dupe: https://news.ycombinator.com/item?id=45665752