[LAD] Lv2 port replication [was Re: the role of lv2 extensions]

On 10/8/2009, "David Robillard" <dave@email-addr-hidden> wrote:

>On Tue, 2009-08-11 at 09:57 +1200, Jeff McClintock wrote:
>> > David Robillard -
>>
>> > Anyway, ...replication in basic form is pretty straightforward: the host
>> > needs a way to pass a 'replication factor' to the plugin. This raises
>> > a
>> > few obvious questions:
>> >
>> > - Should changing this at run-time be possible? This is more useful
>> > with polyphony than with replication for multi-channel purposes. This
>> > raises nasty realtime issues, but since buffer allocation is the host's
>> > problem and a clever host could possibly do it, I think the spec should
>> > make this possible. Maybe there are problems with internal plugin data
>> > that needs to replicate as well but in a non-realtime way though?
>>
>> I have written plugins that support port replication. In my case they
>> *appear* to do so in realtime, but don't actually.
>> The host re-instantiates a replacement (with the extra ports), and the
>> same parameter settings, then inserts the replacement in the graph 'swapping
>> out' the old instance (and destroying it). This happens pretty darn fast -
>> milliseconds.
>
>This is generally how stuff like this has to happen. Allocate and set
>up in some other thread, then replace in the process thread (usually
>just some pointer swapping).
>
>However, instantiation of a plugin isn't necessary a fast operation
>here. In some cases it could take much, much longer than a few
>milliseconds (plugins are free to do I/O or whatever they please at
>instantiation time). It is probably best to keep replication separate
>from instantiation for this reason.
>
>> The advantage is a minimal, simple API - when a plugin in created it
>> queries it's 'replication factor' and adjusts itself accordingly. I don't
>> need to support changes 'on the fly' while the plugin is processing audio
>> (which could be difficult to perform within the constraints of realtime
>> operation (without memory allocation etc).
>> So you can avoid the nasty realtime issues, yet easily support run-time
>> flexibility.
>
>Sure, I don't think having new voices allocated in hard realtime is
>really necessary or feasible. Having the number of voices easy to
>increase while the plugin rolls without dropouts would be very useful
>though (e.g. the user increasing the maximum polyphony).

Hi all,

I've been thinking about this dynamic ports idea, but without looking at
the specification and without understanding how LV2 hosts work so much...

So a few thoughts and/or questions:

creation of a port property which specifies that a port should be
replicated to accommodate the number of channels the plugin will process.

i keep thinking about arrays. passing an array of outputs to connect to
the plugin's inputs. null terminated array ( but this would require a
new connect() method in the lv2core, which probably is a bad solution ).

or

example: a DC offset removal plugin for a stereo stream

instead of specifying 'in_left' and 'in_right', we just have 'in'.
the 'in' port is specified with portReplicable (or some such). as the
plugin is operating on a stereo stream, two ports are created 'in0'
and 'in1' (or in1 and in2), then these ports are connected as usual.

the plugin needs to discover if the host supports portReplicable??? if
the host does not support it, it will do things the old fashioned way -
and there'd be two plugins for left + right - so the plugin will know
because the host will give it the number of channels to process.

so in LV2 how would the host tell the plugin how many channels the plugin
is to process?

via const void* extension_data.

having the channel number appended to the port name ( 'in0', 'in1') -
am i right in thinking this would be down to the host to do as it reads
the .ttl?

regards,
james.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Aug 11 20:15:02 2009