LV2 LADSPA

[grammoboy2]

Just a note for your interest: the original author of non-mixer once suggested that it would have been better to write a wrapper from LV2 to LADSPA, instead of adding LV2 support to non-mixer. Clap is a more simple format, but the ideal was that a plugin format was just a header file IIRC.

[Stazed]

I believe this type of wrapper could only be implemented on the plugin side, by the plugin developer. It would allow an LV2 plugin to run in a LADSPA only host, with all the limitations of LADSPA features. The original author only wanted to support LADSPA format. It is unnecessary if the host already supports the other plugin formats.

[grammoboy2]

I thought he meant some generic wrapper from lv2 to ladspa, so those LV2 plugins could work as ladspa in non-mixer. Looking at the plugins of @sadko4u, they're available as LV2 and ladspa. He might be better suitable to say what is possible here.

[Stazed]

I'm not sure why/what point you are trying to get across. This project supports LADSPA, LV2, CLAP, VST3 and VST(2), so there is no need for any wrapper with this host. Just pick whatever format you prefer... that is available from the plugin developer.

[grammoboy2]

I just shared some (historical) information about how the original author looked at adding LV2 to non-mixer and that he thought the better solution to the problem was such a wrapper to ladspa. For mixing plugins I think that makes sense, but that's not really important here. What you do with it is up to you of course, but always interesting and valuable to know the considerations of the original author and designer, at least that is what I think. Feel free to close this issue, or maybe @sadko4u has something valuable to share about the possibilities of such a lv2 to ladspa wrapper.

[Stazed]

I just shared some (historical) information about how the original author looked at adding LV2 to non-mixer and that he thought the better solution to the problem was such a wrapper to ladspa.

Could you show me some documentation from the original author of this (historical) information? Also, any documentation about how this wrapper implementation is supposed to work on the host side from the original author. I really cannot comprehend how this could be done by the host in a way that would make it "better".

[grammoboy2]

I assume you know the original author rejected the LV2 patch. Instead of sending him the LV2 patch to make LV2 plugins work in non-mixer, the LV2/LAD community could have better written a wrapper, so those LV2 plugins could run as LADSPA plugins in hosts like non-mixer. That is how I understood him. Given that @sadko4u is able to provide LADSPA versions of his LV2 plugins (which is nice), he might have suggestions on how such a wrapper could look like, but that's beyond my scope.

[sadko4u]

Hello! Short statement about LSP Plugins and LADSPA support. Being a primary developer and mainainer of LSP Plugins, I consider LADSPA plugin format as outdated plugin format. Here are some fundamental features lacking in LADSPA:

• MIDI support. LADSPA provides absolutely nothing about it. DSSI tried to solve the issue but now we have LV2 which is times better.
• No string argument support. You can not pass path to some file located on file system to a plugin. You can workaround it by specifying some index of record in some special text file... But this is very tricky solution and requires non-trivial actions from a user and may contain potential breakage of session configuration when the index of a record suddenly changes.
• No GUI support. For a trivial plugin with 10 parameters it's okay. But when you try to implement something more complicated, then you're in trouble.

So, actually, not all of LSP Plugins can be present as LADSPA. We try to keep compatibility as possible but sometimes it is not possible at all.

[sadko4u]

LSP Plugins have their own internal plugin interface and plugin format which allows to introduce wrappers to any other plugin format. This allowed to recently add CLAP and VST3 support.

[grammoboy2]

Hello! Short statement about LSP Plugins and LADSPA support. Being a primary developer and mainainer of LSP Plugins, I consider LADSPA plugin format as outdated plugin format. Here are some fundamental features lacking in LADSPA:

* MIDI support. LADSPA provides absolutely nothing about it. DSSI tried to solve the issue but now we have LV2 which is times better.

* No string argument support. You can not pass path to some file located on file system to a plugin. You can workaround it by specifying some index of record in some special text file... But this is very tricky solution and requires non-trivial actions from a user and may contain potential breakage of session configuration when the index of a record suddenly changes.

* No GUI support. For a trivial plugin with 10 parameters it's okay. But when you try to implement something more complicated, then you're in trouble.

So, actually, not all of LSP Plugins can be present as LADSPA. We try to keep compatibility as possible but sometimes it is not possible at all.

Thanks for the info. The question is whether those limitations are a real issue for something like non-mixer, this is subjective. Gui not so much (it's a choice) and no MIDI not a problem as well probably. Those limitations where already known at the time LV2 was rejected for non-mixer I think.

LSP Plugins have their own internal plugin interface and plugin format which allows to introduce wrappers to any other plugin format. This allowed to recently add CLAP and VST3 support.

And would it be easy for other 'vendors' to use the wrappers?

[sadko4u]

LV2 like other modern plugin formats is much more complicated. There are several things done by plugin 'Under the hood' which the usual user doesn't even notice:

• state store and load. Plugin can contain it's own complicated state. For example, it can generate audio samples and store them in memory. Modern plugin formats provide corresponding abilities for serialize and deserialize internal state. LADSPA has nothing to do about it.
• offline data processing. That means, if some input of the plugin changes, it should do some data processing not compatible with real time audio processing. RT processing means that plugin can not issue any calls that can block, even it is not performed to do memory allocations. All this job is done in an additional executor thread. Some plugin formats like LV2 provide special interface for non-realtime data processing.

The state serialization/deserialization is very IMPORTANT part of modern plugins. You can not just save it's input parameters and just consider plugin configuration is valid.

And would it be easy for other 'vendors' to use the wrappers?

I think vendors that do not distribute plugins for only one plugin format already came to such solutions. Even VST3 SDK contains implementation to AAX and VST2.x wrappers.

[grammoboy2]

And would it be easy for other 'vendors' to use the wrappers?

I think vendors that do not distribute plugins for only one plugin format already came to such solutions. Even VST3 SDK contains implementation to AAX and VST2.x wrappers.

Heh, with 'vendors' I meant other projects in the community which are distributing LV2 plugins and like to distribute them as ladspa as well, similar to what you're doing.

[sadko4u]

I have no answer to it. It is much easier just to ask vendors about their policy. The only thing is, distributing plugins in multiple plugin formats is much harder and is more time consuming job.