Re: [LAD] Design of similar LV2 plugins

I don't know if that would fit that I would need.
More complex plugins like the Dynamic Waves with 4, 6, or 8 VCOs and
Envelops, they have the same number of inputs, outputs but a completely
different number of Comtrol Ports.

I was thinking in the simpler line of having 3 different ttls calling the
same binaries, but I can't find a way to find a way in the plugin to find
out the nunber of port referenced in the ttls.

I could always have 3 ttls with 3 shared objects. Each shared object could
call a final shared object where the plugin code could actually be. But I
would have to add additional code to find the right index of the right
controls port which would increase the amount of cpu resource used or I
would have to organise the ports in such a way it wouldn't be very user
friendly.

At the end of the day, I don't know if any of your or my solution is worth
it compared to just a bit of extra copy/past!

Thanks anyway,

Aurélien

On Fri, Dec 5, 2014 at 5:24 PM, David Robillard <d@email-addr-hidden> wrote:

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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat Dec 6 04:15:06 2014