<div dir="ltr">I don't know if that would fit that I would need.<div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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!</div><div><br></div><div>Thanks anyway,</div><div><br></div><div>Aurélien</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 5, 2014 at 5:24 PM, David Robillard <span dir="ltr"><<a href="mailto:d@drobilla.net" target="_blank">d@drobilla.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 2014-11-30 07:31, Aurélien Leblond wrote:<br>
> While porting AlsaModularSynth modules to LV2 plugins, I was wondering<br>
> something... AMS has some similar modules where the only thing changing is<br>
>  the number of inputs (Mixer with 2, 4 or 8 inputs), the number of outputs<br>
> (CV source with 2, 4 or 8 outputs) or the number of VCOs/Envs/etc.<br>
> (DynamicWaves with 4, 8 or 16 VCOs).<br>
><br>
> In AMS there is only one class for such plugins and AMS would pass the<br>
> number of inputs/outputs/sections/etc. when creating the different modules.<br>
> I couldn't find an easy way to reproduce this in LV2 plugins, therefor so<br>
> far I have been creating different LV2 plugins for each and everyone of<br>
> them and doing a lot of copy/past/editing.<br>
><br>
> That let me to wonder if there wouldn't be a better way.<br>
><br>
> The pros:<br>
> - it's easier to maintain if I have only one class<br>
> - it's a lot less boring than doing a lot of copy/past/editing - I have<br>
> been doing it only for simple ones so far like Mixers or CV source, but now<br>
> I'm starting to port DynamicWaves which is way more complex<br>
><br>
> The Cons:<br>
> - I have the feeling that gaining on code simplicity actually decrease the<br>
> performance when the plugin is running - i can imagine it to be less<br>
> strainuous on the CPU to have simple code instead of dealing with loops and<br>
> arrays<br>
><br>
> Being a rare case I can't imagine the need to have this supported directly<br>
> in LV2, but I was wondering if people with more talent than me in creating<br>
> audio software might have some advice?<br>
<br>
</div></div>AU works this way, but LV2 does not currently have an extension for it.<br>
<br>
There are two aspects that I see:<br>
<br>
1) Dynamic ports<br>
<br>
2) Multiple channels in a single port (one "port", but mono, or stereo,<br>
or whatever)<br>
<br>
I don't know if 2 is worth it (additional complexity) but it has some<br>
advantages.  If your number of  ports was actually the same, and you<br>
only change the number of channels, then 2 can be done with just a new<br>
port type (buffer of pointers to buffers or some such).<br>
<br>
To do 1 truly dynamically after the plugin has been instantiated would<br>
be quite a burden on hosts, almost all of which assume a static set of<br>
ports for an existing plugin.  We could do it at instantiation time<br>
(probably by passing options) easily enough, though.<br>
<br>
The question is, how to actually describe the port (type, value range,<br>
and so on)?  A free for all where you have to completely describe a new<br>
one, or define 'templates' in the data and simply say you want n of<br>
those at instantiation time.<br>
<br>
I don't think it would actually be that hard to do, but nobody has<br>
really expressed an active interest in it yet.  Most of the difficulty<br>
would be for hosts, which generally assume they can figure out how many<br>
ports of whatever type(s) exist from looking at the data.  I think it<br>
would need to be done in such a way that the default looks like a normal<br>
non-dynamic-ports plugin so it would work in existing hosts, but smarter<br>
hosts could see the option to tinker with the port signature and do so<br>
if they please.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
dr<br>
<br>
<br>
</font></span></blockquote></div><br></div>