[LAD] Design of similar LV2 plugins

[David Robillard]

On 2014-11-30 07:31, Aurélien Leblond wrote:
> While porting AlsaModularSynth modules to LV2 plugins, I was wondering
> something... AMS has some similar modules where the only thing changing is
>  the number of inputs (Mixer with 2, 4 or 8 inputs), the number of outputs
> (CV source with 2, 4 or 8 outputs) or the number of VCOs/Envs/etc.
> (DynamicWaves with 4, 8 or 16 VCOs).
> 
> In AMS there is only one class for such plugins and AMS would pass the
> number of inputs/outputs/sections/etc. when creating the different modules.
> I couldn't find an easy way to reproduce this in LV2 plugins, therefor so
> far I have been creating different LV2 plugins for each and everyone of
> them and doing a lot of copy/past/editing.
> 
> That let me to wonder if there wouldn't be a better way.
> 
> The pros:
> - it's easier to maintain if I have only one class
> - it's a lot less boring than doing a lot of copy/past/editing - I have
> been doing it only for simple ones so far like Mixers or CV source, but now
> I'm starting to port DynamicWaves which is way more complex
> 
> The Cons:
> - I have the feeling that gaining on code simplicity actually decrease the
> performance when the plugin is running - i can imagine it to be less
> strainuous on the CPU to have simple code instead of dealing with loops and
> arrays
> 
> Being a rare case I can't imagine the need to have this supported directly
> in LV2, but I was wondering if people with more talent than me in creating
> audio software might have some advice?

AU works this way, but LV2 does not currently have an extension for it.

There are two aspects that I see:

1) Dynamic ports

2) Multiple channels in a single port (one "port", but mono, or stereo,
or whatever)

I don't know if 2 is worth it (additional complexity) but it has some
advantages.  If your number of  ports was actually the same, and you
only change the number of channels, then 2 can be done with just a new
port type (buffer of pointers to buffers or some such).

To do 1 truly dynamically after the plugin has been instantiated would
be quite a burden on hosts, almost all of which assume a static set of
ports for an existing plugin.  We could do it at instantiation time
(probably by passing options) easily enough, though.

The question is, how to actually describe the port (type, value range,
and so on)?  A free for all where you have to completely describe a new
one, or define 'templates' in the data and simply say you want n of
those at instantiation time.

I don't think it would actually be that hard to do, but nobody has
really expressed an active interest in it yet.  Most of the difficulty
would be for hosts, which generally assume they can figure out how many
ports of whatever type(s) exist from looking at the data.  I think it
would need to be done in such a way that the default looks like a normal
non-dynamic-ports plugin so it would work in existing hosts, but smarter
hosts could see the option to tinker with the port signature and do so
if they please.

-- 
dr


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20141205/6ec9bf85/attachment.pgp>