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 <[email protected]> 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
