Well this is a kick in the nuts: VST2 plug-ins

[Urs]

The last time I used the word "complicated" in this forum was last year, so I hope people aren't offended by something I haven't said exactly like Markus' quoted me

[Urs]

Separation between UI and DSP itself isn't the issue IMHO and should be enforced by API design.

I would tend to disagree with you here. I think a plug-in API should be only a communication protocol between a host application and a plug-in component (I=Interface).

While GUI/DSP separation is a good practice, it may not make sense for all cases, or at least be implemented differently depending on what the plug-in is doing. All attempts so far to try to enforce a structure by a plug-in API resulted in monsters such as VST3 (and there are other cases I cannot talk about here because of NDAs). It always causes way too many problems for both hosts and plug-ins, just because most of them will not fit into the box (you cannot make it flexible enough), and enforcing a structure also adds way too many constraints on both sides.

A communication protocol such as a plug-in API should remain simple, with as few data structures and functions as possible, and be as much language agnostic as possible. If you have to read the entire documentation just to write a very simple plug-in, and make assumptions or guesses in which order/threads functions may or may not be called to avoid crashes or undefined behavior, then it sounds like a failure to me.

A protocol defines how two components should communicate with each other (precisely), but not how they should be implemented (at all).

What drives me nuts is that an audio plug-in remains a fairly simple concept compared to many other computer systems/software. And yet most APIs are an incredible mess that can be interpreted in so many ways that you won't find 2 manufacturers that understood them the same way!

Sorry, I'm currently a bit all over the place.

What I mean is, there should be getters and setters for complex data or parameters that are not simple types, and these should be immediate. Instead of "enforce" I probably should have said "invite".

[Blue Cat Audio]

Sorry, I'm currently a bit all over the place.

What I mean is, there should be getters and setters for complex data or parameters that are not simple types, and these should be immediate. Instead of "enforce" I probably should have said "invite".

If that's data that is internal to the plug-in, I guess it could indeed be an optional service in the API. The only case where such APIs are necessary is when you want the host to provide a service to help GUI and DSP communicate with each other when loaded in separate processes. I have yet to see an implementation that is flexible enough and also lets you know (or optimize) when both are in the same process though .

Relying on the host application to perform the communication is sometimes not possible, especially when protocols are asynchronous or not well defined as you mentioned. Also, if not well specified, it leaves a lot of space for interpretation and different behavior depending on the host, which is something you usually want to avoid.

[Urs]

I think, if it's important to some people, there's no reason not to provide it in an API. If a host doesn't support running the UI in a separate process, it can just pass the data on as is. If a host does, and if the plug-in indicates the possibility, the host can deal with it.

But either way, I just don't see a point in doing it asynchronously. IMHO the example of AU demonstrates that everything imaginable is possible with a synchronous interface, which does not put a large burden on the plug-in developer side. That's not to say that it's perfect or simple, just that this works somehow.

[Guillaume Piolat]

As said above, LV2 has http://lv2plug.in/ns/ext/instance-access
To avoid UI/DSP separation you would declare this as requiredFeature ; which let the hosts decide whether they can load this.

Example:

Code: Select all

vendor:ui
    a ui:WindowsUI;
    lv2:optionalFeature ui:noUserResize, ui:resize, ui:touch ;
    lv2:requiredFeature opts:options,
                        urid:map,
                        <http://lv2plug.in/ns/ext/instance-access> ;
    ui:binary <path-to-binary.dll> .

It is the best of both worlds.

[Music Engineer]

We already tried this in the early 2000's. It was called GMPI (General Music Plugin Interface). I am suprised it has not been mentioned here so far.

[...]

The specification was finally finished after months of mailing list activity, then the MMA said "great, now we're doing an implementation behind closed doors", and everybody ran screaming from the room. GMPI was never heard of again. Please do not ask the MMA to do this again.

this is an interesting piece of history. i didn't know that. but i don't understand what is the issue when someone does an implementation behind closed doors? i mean, what counts is the specification - if someone is unhappy with a particular implementation, they are free to write their own. i guess,, what they would have come up with would then count as reference implementation, but it doesn't need to be the only one

[mr.ardour]

this is an interesting piece of history. i didn't know that. but i don't understand what is the issue when someone does an implementation behind closed doors? i mean, what counts is the specification - if someone is unhappy with a particular implementation, they are free to write their own. i guess,, what they would have come up with would then count as reference implementation, but it doesn't need to be the only one

my own take on this is that it was like a slap in the face. A group of us all worked on the specification for months, doing everything in the open, agreeing/disagreeing, and above all else working on the assumption that what was happening would result in a license-free, royalty-free standard not controlled by a single company (or organization).

When the MMA insisted that stage 2 would be done behind closed doors, it just felt like the opposite of everything that we'd been doing. There was also the question of just who was going to do the work, since the GMPI working group already included more or less the entire brain trust of the audio software world minus apple, digi and steinberg.

I think those of us with some understanding of how these things go understood that the implementation phase would likely reveal things about the specification that were not apparent at the beginning, and that the specification would thus likely need some tweaking. The MMA's intended process seem to raise big questions about how that would happen.

It is hard for to imagine this happening today. In the early 2000s when I was still going to NAMM and AES and so forth, open source culture was very foreign to this industry. MOTU people dismissed Linux as a bunch of "dirty hippies" (this is a direct quote). In 2021, even if most users are still attached to proprietary operating systems, the general culture for software and technology development has changed significantly. Most of the people participating in this thread, even if they make a living from proprietary plugin development, understand how open source and design happens, they understand how it can at least match closed design and development processes, if not surpass it. The emergence of Linux, if not as a desktop platform then as an engine driving huge amounts of contemporary computing technology, and some historical awareness of how the standards that make up the internet actually happened have really changed the landscape here. If the MMA tried this today, they'd be laughed out of the room. Back then, we just groaned and went back to our regular activities.

[Music Engineer]

thanks for the explanations. that's really a sad situation. but if, as you said, LV2 actually captures most of the consensus about how such a thing should be done, then maybe it's just as good

working on the assumption that what was happening would result in a license-free, royalty-free standard not controlled by a single company (or organization).

they didn't intend to make it subject to (unreasonable) licensing restrictions and/or royalty payments, did they?

the implementation phase would likely reveal things about the specification that were not apparent at the beginning, and that the specification would thus likely need some tweaking. The MMA's intended process seem to raise big questions about how that would happen.

ok, yes - that makes a lot of sense.

[mr.ardour]

they didn't intend to make it subject to (unreasonable) licensing restrictions and/or royalty payments, did they?

it remained the stated goal that GMPI would be license and royalty free. The MMA's justification for the closed door stage 2 was something about "it's just better to do it this way".

[lkjb]

Also, I don't get why GUI/DSP separation is stated as such an issue with VST3.

IIRC the main issue was that sending or requesting data was asynchronous. Our UIs weren't guaranteed to receive the information on the process it needed, when it needed it. That's because, due to the modular nature of our codebase, much of the information about a plug-in exists at runtime, not at compile time, i.e. it's built up programmatically.

I agree with Urs. It is badly designed. It is getting an issue with

- more complex plugins
- plugins with animated realtime-displays like waveforms
- plugins that come with an own preset-manager

Steinberg says 'it is not an issue' because there is a single-component example in the SDK (v3.7) but

- the single-component example of the SDK does not support VST 2.4
- the single-component example of the SDK does not work as AU (no audio output)
- the single-component example of the SDK is completely messy and very difficult to understand. I needed one month to sort, fix and rewrite the code to build an own empty project from it

I also agree with the the point where Urs said "Steinberg made VST3 so complicated to slow down plugin-development of this format intentionally". And they got a reason for this: They want to sell they own plugins

Urs didn't fully quote me, ommiting the SingleComponent where you added some points. As I said I built ReFine using only the VST3 (I think 3.6) SDK. I was able to use the VST2 wrapper without much effort, although I didn't get AU up and running. The latter might be related to my abhorrence for the AudioUnits format.

But at least to me the argument that VST3 needs separate GUI/DSP which have to communicate asynchronically is moot. I don't see much difference to LV2 where it is an option, too.

[ghettosynth]

they didn't intend to make it subject to (unreasonable) licensing restrictions and/or royalty payments, did they?

it remained the stated goal that GMPI would be license and royalty free. The MMA's justification for the closed door stage 2 was something about "it's just better to do it this way".

It's not necessarily wrong, no? How many pages ago was it that mulab and Urs discussed taking their standards conversation off line in order to keep it focused? I'm not suggesting that the MMA took the right approach, in fact, one could argue that since GMPI failed, that they didn't. (Also not really being critical of taking any important conversation off of KVR, TBH) I'm saying that the thought was probably driven by how challenging it is to get everyone to agree, and then to continue to get them to agree as a standard evolves. Standards are hard and time is never on your side with trying to adopt a new standard.

It's taken decades to get an open standard, that was fueled by an attempt at open standards from key industry players, to the point where it is in one quasi-mainstream commercial DAW. As I said pages ago, I think that adoption is the hard part and I think that the story of GMPI tells that beautifully. If you couldn't get the three horseman to come to the table when the industry wasn't hot enough to melt butter, then I find it rather unlikely that anything is going to be different now.

At any rate, I'm glad to see more discussion of LV2. I have no dog in this fight, I've just seen the "we need a new standard" story repeat itself in the same sad way over the years.

[FigBug]

Not Ardour !

I fully explain why Ardour will never (well, never is a long time, but ...) implement plugin sandboxing here: https://ardour.org/plugins-in-process.html

Disagreement with the rationale laid out here is fine, but I see a lot of people who don't seem to actually understand the issues surrounding this matter.

It may work for 4 track Bitwig session with 12 plugins or thereabouts but it's not suitable for any large scale work, and certainly not at the very low latency settings that Ardour can be run with.

I think you are exaggerating the performance hit caused by sandboxing. I created a test edit in BitWig with Serum, a compressor and an EQ on a track. In BigWig, I can get to 60 tracks before I get CPU dropouts. I recreated the same project in Ardour with the same settings (44.1 / 64 samples), when I got to 60 tracks, Ardour was using between 85% and 95%.

The performance is in the same ballpark, BitWig can obviously handle more than 4 tracks. Logic Pro sandboxes plugins now as well, and performance isn't significantly degraded.

[FigBug]

https://lv2plug.in/gmpi.html

Plugins must not be expected to support dynamic sample rates. The sample rate must be set very early in the life of the plugin and not changed.

All looks sensible except this. Does that mean if the user changes their sample rate, you need to reload all the plugins?

Not reload. Reinstantiate. Totally different things. You don't unload/load the shared object(s) corresponding to the plugin (DLLs). You call a "teardown" method on the existing plugins, and then an "instantiate" method to recreate them all, with the same state as before (except for the new sample rate).

Real world workflows do not involve frequent sample rate changes.

How do handle this in Ardour? I just tried exporting an audio file that wasn't at the project sample rate. It seemed too fast to have reinstantiated every plugin. Does it render at project sample rate and then resample?

[S0lo]

I have a question. Does LV2 has a history/tendency of repeated deprecation over and over? Or is the API mostly committed? Is the design consistent over time? In other words, do the authors care about backward compatibility?

[x42]

I have a question. Does LV2 has a history/tendency of repeated deprecation over and over? Or is the API mostly committed? Is the design consistent over time? In other words, do the authors care about backward compatibility?

The core API is stable and there is also a great effort to remain backwards compatible.

The flip side to this is that it is harder to extend the LV2 spec. The maintainer is known to only accept extensions into the standard that can be maintained long-term.

---

There are only two deprecated interfaces, notably the first iteration of MIDI Event ports, but that was about 10 years ago now and the change was motivated by plugin-devs. You can see for yourself https://lv2plug.in/ns/