[LAD] "enhanced event port" LV2 extension proposal

[David Olofson]

On Wednesday 28 November 2007, Dave Robillard wrote:
[...]
> The only problem that needs to be handled is how to get the type in
> there.  I would like to find a good solution to this problem that's
> as extensible as URIs but doesn't actually stick a URI in the event
> struct (there are a few other future extensions that have the same
> problem. strcmp of URIs in the audio thread is, as you say,
> completely out of the question, but so is handing out a flat numeric
> space.  This is /the/ problem that needs solving here, and I'm
> desperately trying to guide the conversation in a direction that
> will get it solved nicely ;)

I don't know if this is applicable here, but for Audiality 2 I'm 
dealing with this on the connection level. Each control is a port 
like any other, meaning it has a name, a protocol URI and a few other 
parameters that the host needs to know what can and cannot be 
connected. If two ports have the same URI, they can be connected, and 
that's it, basically. Event semantics ("structured 
stream", "commands" etc) and data fields are left to the plugins that 
implement the ports, so the host doesn't even need to know what the 
plugins are talking about. (This is a "direct connection" model; data 
is not normally piped through the host.)

On the physical level, I still have ports share event buffers (or 
rather, queues in this case) so plugins don't have to sort/merge or 
poll umpteen queues all the time. "What event goes where" is decided 
by means of filling an address field with an opaque cookie value that 
the plugin generates upon connection. The cookie can be ignored if 
there's one queue per port, or it can be a fully specified 
plugin-wide port index if the plugin uses a single event queue, or 
anything in between.

Multiple queues...? Yes, A2 plugins can use multiple queues when that 
suits the implementation better. (Multiple inner loops, rather than 
running the whole synth, all voices, or whatever, one sample at a 
time.) Thus, a plugin doesn't have to mess around with the events to 
get them to the right places in the right order. It just creates one 
queue per voice/strip/section/whatever loop and hands the right 
queues out when connections are made. This means an "event target" 
also needs to contain a queue pointer.

Of course, one could just use one queue per plugin and use only cookie 
addressing, but I decided to allow multiple queues to eliminate most 
of the event dispatching complexity you'll otherwise have in any 
non-trivial plugin.

It seems to be a simple and efficient solution, but I could be missing 
something, of course. Remains to see when I have some more serious 
code running. :-)


//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'