On 11/8/2009, "David Robillard" <dave(a)drobilla.net> wrote:
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've been trying to figure out if a port should have a property applied
to it to indicate to the host it is a multichannel port or if a new sub
class of port should be created. The latter implies further subclasses
to match the existing port subclasses so I'm almost sure it would be
more sensible for multichannel ports to be specified via a property.
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.
It's slowly sinking in... Slowly.
having the
channel number appended to the port name ( 'in0', 'in1')
Port names/symbols (symbols) must not be interpreted in ways like this,
ever.
Ok, that's good.
BTW, I'm trying to figure this out for my own experience rather than
making an pretense toward creating a multichannel LV2 extension (just in
case anyone thinks otherwise).
cheers,
James.