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

[mr.ardour]

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?

So .. the latter. Resampling during export happens to the audio after it has been generated, not during the processing that would involve plugins.

Also, I wanted to note that the state changes required in most plugins if they did handle a sample rate change are almost as extensive as a full reinstantiation. This is not true of all plugins, but the bigger the plugin, the simpler it becomes to deal with an SR change by just tearing it down and reinstantiating with the new SR.

[FigBug]

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?

So .. the latter. Resampling during export happens to the audio after it has been generated, not during the processing that would involve plugins.

Also, I wanted to note that the state changes required in most plugins if they did handle a sample rate change are almost as extensive as a full reinstantiation. This is not true of all plugins, but the bigger the plugin, the simpler it becomes to deal with an SR change by just tearing it down and reinstantiating with the new SR.

Interesting. In the DAW I work on, we allow renders at any sample rate. This is a fairly common source of support requests, as a fair number of plugins don't support sample rate changes (even though the plugin APIs say they should) and then their project renders out of tune.

Looking at other DAWs, we are one of the few that allows this. Perhaps I should pull the feature out, but I wonder how many people would complain.

[x42]

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?

Changing the sample-rate of a soundcard cannot be done click-free to begin with.

I expect many plugins do not get this right either. EQs GUIs will have to change their display grid, and potentially remove bands (think switching from 96kHz to 48kHz).
Convolvers need to resample the IR, sample-players reload (or resample) samples. samplers resample (ideally in a non-destructive way,... and I won't be surprised if changing the sample-rate changes the sound of some reverbs or distortion effects.

I think it is rather reasonable to pick the sample-rate for a given session early on.

[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?

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/

Thats good to know. Although I do see a few more deprecated small features/functions here and there when I checked the history of some specification. But sure I understand.

I've used a few APIs over the years (some none audio). One deperecation strategy that I like is when deprecation does not actually mean "removal". But only that the feature is not recommended or supported any more. This signifies to new developers to avoid the old feature and at the same time keeps backward compatibility intact.

An even better approach is when the API maintainer cares to internally re-implement the deprecated features using the new features. This avoids clutter and proves that the new stuff can actually do the old stuff and more. (Edit: though the flip side here is that this can introduce bugs).

IMHO these strategies also have a hidden effect on the maintainer him self. Not to rush into new features unless he is sure they are useful and make sense, because he knows that he's going to maintain them for a long time because he is committed to backward compatibility. It avoids the kind of "lets try this and see what happens" additions. As you've mentioned:

The maintainer is known to only accept extensions into the standard that can be maintained long-term.

[mr.ardour]

Thats good to know. Although I do see a few more deprecated small features/functions here and there when I checked the history of some specification. But sure I understand.

I've used a few APIs over the years (some none audio). One deperecation strategy that I like is when deprecation does not actually mean "removal". But only that the feature is not recommended or supported any more. This signifies to new developers to avoid the old feature and at the same time keeps backward compatibility intact.

The thing about LV2 is that outside of core, anyone can extend the API. You don't need to get anyone to agree with you ... with the caveat that if you don't get at least a single host to implement your extension, it's completely pointless. LV2 was designed to allow an arbitrary expansion of plugin behavior without the need for some committee to agree on it beforehand. VST does have some scope for "vendor specific extensions", but AFAIU, these are less powerful than the possibilities in LV2.

On the upside, this provides great flexibility for host developers who create their own bundled plugins - you can add things like the inline UIs that x42 added specifically for Ardour/Mixbus.

On the downside, you can get a proliferation of extensions that could be poorly designed, not widely supported, and find it hard to discover their current provenance. David Robillard wrote about this in his good/bad/ugly document.

In LV2 land, the main process that relates to deprecation is one between host developers and plugin developers, not the "owner" of the plugin API.

[S0lo]

The thing about LV2 is that outside of core, anyone can extend the API. You don't need to get anyone to agree with you ... with the caveat that if you don't get at least a single host to implement your extension, it's completely pointless. LV2 was designed to allow an arbitrary expansion of plugin behavior without the need for some committee to agree on it beforehand. VST does have some scope for "vendor specific extensions", but AFAIU, these are less powerful than the possibilities in LV2.

On the upside, this provides great flexibility for host developers who create their own bundled plugins - you can add things like the inline UIs that x42 added specifically for Ardour/Mixbus.

On the downside, you can get a proliferation of extensions that could be poorly designed, not widely supported, and find it hard to discover their current provenance. David Robillard wrote about this in his good/bad/ugly document.

In LV2 land, the main process that relates to deprecation is one between host developers and plugin developers, not the "owner" of the plugin API.

hmm, I see. Well I bet the core API is very enough for most developers (Or isn't it?). As long as its clearly distinguished from the external extensions.

[mr.ardour]

hmm, I see. Well I bet the core API is very enough for most developers (Or isn't it?). As long as its clearly distinguished from the external extensions.

Yes, if you're writing a fairly "ordinary" plugin (and who's going to admit to this? ) then core will likely be all you need.

[mystran]

Also, I wanted to note that the state changes required in most plugins if they did handle a sample rate change are almost as extensive as a full reinstantiation. This is not true of all plugins, but the bigger the plugin, the simpler it becomes to deal with an SR change by just tearing it down and reinstantiating with the new SR.

I would like to argue that in most cases changing sampling rate on the fly is rather trivial to a plugin: you go into suspended state, do a partial reinitialization and start restart processing.

Meanwhile if you fully teardown and reinstatiate plugins, you might end up tearing down and reloading things like wavetable mipmaps, cached GUI images, preset databases, even thread pools. Many hosts don't bother unloading dynamic objects when the last plugin instance is disposed, so unless you want to keep all that stuff around until the host exists, you need to drop it when there are no instances active.

There are plenty of reasons why a complex plugin (especially the first instance) can take 10 seconds to start while changing the sampling rate of the same plugin might cost no more than a regular reset (eg. when you hit stop twice in most hosts).

[EvilDragon]

Agreed with mystran. SR change can be handled very well by the plugin and cost much less than a full teardown.

[Vokbuz]

The thing about LV2 is that outside of core, anyone can extend the API. You don't need to get anyone to agree with you ... with the caveat that if you don't get at least a single host to implement your extension, it's completely pointless. LV2 was designed to allow an arbitrary expansion of plugin behavior without the need for some committee to agree on it beforehand.

I guess there is no problem with this while LV2 is quite niche format. When it becomes widely adopted, it is very likely to face fragmentation problem like Android does.

[x42]

The thing about LV2 is that outside of core, anyone can extend the API. You don't need to get anyone to agree with you ... with the caveat that if you don't get at least a single host to implement your extension, it's completely pointless. LV2 was designed to allow an arbitrary expansion of plugin behavior without the need for some committee to agree on it beforehand.

I guess there is no problem with this while LV2 is quite niche format. When it becomes widely adopted, it is very likely to face fragmentation problem like Android does.

Perhaps. The internet hasn't fragmented because of conflicting RFCs yet, so there's some hope for open standards

It is really up to host-authors who may want to provide additional features to plugins, and there are not a lot of those. While there are plenty of DAWs, it is really only those that currently support both AU and VST that are contenders to add LV2 support in the first place.

It is very much like PreSonus VST2/3 extensions or Cockos Extensions to the VST SDK. Except with LV2, those extensions can eventually become an official part of the spec.

In the big picture, custom extensions mainly make sense for devs who are in control of both a host and plugins and want tighter integration. e.g. "devices" in Abelton or Bitwig, or "Console 1" with the PreSonus Extensions.

A simple current real-world example is an LV2 extension to manage plugin licenses. Harrison Mixbus can be used to manage Harrison XT LV2 plugin licenses. It is an optional host provided feature. The plugins work just fine in other hosts without it.


Anyway I'm still unsure if LV2 is the answer to the issue VST2/3 issues raised on this thread. Except, this thread would not exist if LV2 had been popular before VST3 happened.

[mr.ardour]

The thing about LV2 is that outside of core, anyone can extend the API. You don't need to get anyone to agree with you ... with the caveat that if you don't get at least a single host to implement your extension, it's completely pointless. LV2 was designed to allow an arbitrary expansion of plugin behavior without the need for some committee to agree on it beforehand.

I guess there is no problem with this while LV2 is quite niche format. When it becomes widely adopted, it is very likely to face fragmentation problem like Android does.

As if the plugin/host space isn't already. We have the Reaper VST2 extensions, the Presonus VST2/3 extensions, and a whole variety of one-off behaviors from specific plugins that cause problems for host developers. I remember a conversation with the lead on a proprietary DAW who told me in no uncertain terms that plugins were their worst nightmare (too), and that if it would be possible to just stop supporting them (it isn't) their entire time gladly would. In Ardour land, we just found a case in the last day or two where a single plugin company does something with its plugin GUIs that as far as we can tell, no other company does, and it was breaking things when running the plugins inside Ardour or Mixbus. That's fixed now, but to be honest as a host developer, the variety of behaviors exhibited by plugins is already "a fragmentation problem like Android".

[mr.ardour]

Meanwhile if you fully teardown and reinstatiate plugins, you might end up tearing down and reloading things like wavetable mipmaps, cached GUI images, preset databases, even thread pools.

cached GUI images ... oh dear. You mean pixel-based graphics that won't scale correctly? C'mon people, it's 2021. Vector graphics is the only sane thing right now. Take a look at VCV Rack - every module's GUI is drawn with SVG and scales to any size or resolution. Why would you not want this?

None of the things you've mentioned there take more than a fraction of a second to accomplish. On the other hand, plugins that miss some small detail when the SR is reset just stop working correctly.

Many hosts don't bother unloading dynamic objects when the last plugin instance is disposed, so unless you want to keep all that stuff around until the host exists, you need to drop it when there are no instances active.

If you take the approach that I described (reinstantiating all plugins), you're not going to unload dynamic objects at all. You're just reinstantiating plugins.

[Vokbuz]

As if the plugin/host space isn't already.

Not that much. Problems with "fixed" VST/AU is an easy walk comparing to the potential extension hell.

[Vokbuz]

Perhaps. The internet hasn't fragmented because of conflicting RFCs yet, so there's some hope for open standards

RFCs are not written by "anyone". There is a committee(s) involved. They are not "designed to allow an arbitrary expansion of plugin behavior without the need for some committee to agree on it beforehand".