On Tue, 2009-08-11 at 15:15 +0100, james morris wrote:
> 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.
Something like that; the data side of things is relatively easy.
> 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 ).
The connect method takes a void* pointer, so this is fine. You can
stick whatever kind of data you want in ports without needing a new
connect method.
The question here is probably: array of pointers to buffers, or one big
multi-buffer? The former is probably more flexible.
> 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.
Backwards compatibility is one reason a big multi-buffer (the first part
of which is a single normal buffer) might be good. Though there can
just be a rule something like "if the host doesn't support
multi-buffers, the plugin must expect a single buffer", which seems
fine.
> so in LV2 how would the host tell the plugin how many channels the plugin
> is to process?
That's essentially the problem to solve :)
> via const void* extension_data.
Well, pretty much everything is via extension_data, and/or features.
The usual pattern is to have it return a struct of function pointers.
In other words, you can add whatever functions to the LV2 API you want.
So here, we need something like a function the host calls to tell the
plugin to increase its replication factor. Then rules for when this
function can be called and its semantics etc. etc.
> having the channel number appended to the port name ( 'in0', 'in1')
Port names/symbols (symbols) must not be interpreted in ways like this,
ever.
> am i right in thinking this would be down to the host to do as it reads
> the .ttl?
Reading the .ttl and instantiating the plugin binary are different
times. How the host behaves will depend on things it figured out from
the .ttl though, yes.
Cheers,
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Aug 12 00:15:02 2009
This archive was generated by hypermail 2.1.8 : Wed Aug 12 2009 - 00:15:03 EEST