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

[David Robillard]

On Wed, 2009-08-12 at 21:29 +0100, james morris wrote:
> 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.

A property or class would work.  Probably need both, a class to say "I'm
a multi-port" and some properties to say specifics about it.

There's no limit to the number of classes a port can have as a type.
It's not like single inheritance languages where a port has to be of one
specific type and the class hierarchy has to be strictly designed based
on that.  In practice subclassing doesn't really matter much.

> >> 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.

At a basic high level, there's really only two things to understand
about extension mechanism:

- Features, passed to instantiate, allow the host to pass the plugin
things

- extension_data allows the plugin to return things to the host.

There are no actual restrictions on what these can contain (but there
are best practices that avoid shooting yourself in the foot, so
following existing things is generally wise).

Cheers,

-dr

P.S. The terminology, especially "extension", is unfortunate, but we're
stuck with it now.  I wish that stupid E word was never mentioned.