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

james morris james at jwm-art.net
Wed Aug 12 20:29:20 UTC 2009


On 11/8/2009, "David Robillard" <dave at 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.



More information about the Linux-audio-dev mailing list