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 --'
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu Nov 29 04:15:02 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 29 2007 - 04:15:02 EET