12 Aug
2009
12 Aug
'09
6:39 p.m.
On Wed, 2009-08-12 at 21:29 +0100, james morris wrote:
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.
On 11/8/2009, "David Robillard"
<dave(a)drobilla.net> wrote:
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.
On Tue, 2009-08-11 at 15:15 +0100, james morris
wrote:
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. 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. 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.