11 Aug
2009
11 Aug
'09
3:41 p.m.
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