Vst3 Audio Plugin Format Is Now Mit

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 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.

COM is just 3 predefined calls in the virtual table. CLAP gives you a bunch of pointers to functions, which is similar.

Making a new plugin standard that is gaining wide adoption is big in my head.

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).

(fun fact: the motorcycle Triumph and the undergarment Triumph are two entirely different companies that just happen to share the same name)

They may have “different legal entities” but it’s the same.

https://en.wikipedia.org/wiki/Yamaha_Corporation

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.

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?

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.

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.

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.