30 Nov
2014
30 Nov
'14
1:31 p.m.
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?
Aurélien
5 Dec
5 Dec
6:24 p.m.
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
7:32 p.m.
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(a)drobilla.net> 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
6 Dec
6 Dec
12:32 a.m.
On 2014-12-05 13:32, Aurélien Leblond wrote:
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.
In an ideal world, event-based control, unless they're CV (and actually
need to be).
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.
This is both reasonable and common. Every plugin has a distinct URI, so
you always know which you are in the code.
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.
Just cache the indices appropriately in the descriptor.
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!
Factoring out the common code of several plugin variants which are
extremely similar is surely worth it, I'd say. At least you can just
factor out the run() and pass the appropriate buffers to it, so the
plugins would just be little skeletons whose purpose in life is to do that.
(We should be passing buffers to run() anyway, connect_port() is
idiotic, but that's another discussion...)
--
dr
3636
days inactive
3641
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
2 participants
participants (2)
-
Aurélien Leblond -
David Robillard