Subject: [linux-audio-dev] Plug-in API progress?
From: David Olofson (audiality_AT_swipnet.se)
Date: pe syys 17 1999 - 14:47:15 EDT
Hi folks!
Back from Malta, and it's friday. :-)
Unfortunately, I had too many things to take care of before I left, so I didn't
get any time to get the "real" event system proposal together. I'll play some
with it this weekend.
Actually, I was just wondering if anything interesting has happened these last
two weeks, and if anyone has some nice ideas about dynamic size of events,
strings and those issues.
What I want is a system that can be handled with inline macros, or directly by
user code (clean and extensible on the _binary_ level, that is); that can be
routed between plug-ins efficiently (sorting according to destination and time
etc); that is flexible enough to handle just about any kind of message a
plug-in or a client application might want to send. And of course, it should
be fast and efficient... Simple, eh? ;-)
Just some thoughts for now:
Event port addressing. Or; "How do I find the reciever of my event, and how do
I encode that address into the event?"
So far, I've been thinking along the lines of a DNS + IP style system. That
is, when you create a plug-in, you get a full "address", derived from the
plug-in class name or ID, an instance identifier, and a real Event Port Handle.
(Actually, I'm considering separating Event Ports from plug-in instances, so
that a plug-in can have any number of ports. Not sure if *that's* the right way
to handle things like multitimbral synths, or if the MIDI-like events should
have a channel field. The later sounds better right now... Other ideas?)
Anyway, the Event Port Handle (unsigned int) is what you use to address an
event to a specific port. (It should be safe to send events to ports that don't
exist and that kind of things, to make the system more fault tolerant.)
The handles should be arranged in a way that lets you send the same event to a
group of ports, kind of like IP broadcasting. Not sure if the broadcast
addressing scheme should be multidimensional (ie multiple ways of selecting
groups existing in parallel), or if it's even truly useful. Just an idea,
this broadcasting thing... Either it's just silly, or I forgot what I had in
mind when I first thought of it. If it can't be implemented efficiently, I
think it should be dropped.
Hmm... *thinking. beware: weird ideas may follow...*
Earlier, I think I mentioned using one input buffer and one output buffer for
events. Well, I think there's a better way.
Every Event Port has an input event buffer.
That is, sending an event to some port means finding that port, finding out
where the event buffer currently ends, and then append your events there. No
routing - the sender decides where to send each event.
An event port should be a simple structure to which you can save a pointer
that's safe to use throughout the lifetime of the port. A port struct cannot be
removed before everyone have released it, of course. Performance... Sending
some events would mean some two or three pointer indirections and writing a few
bytes of data for each event.
The events in an Event Port input buffer will, in most cases, have to be sorted
according to the time stamps before scanning the buffer, but that depends on
the nature of the plug-in. Some plug-ins may do the job more efficiently by
sorting on the fly while processing (no need to process buffers from start to
end in all cases), so this should be an optional service in the plug-in host.
Oh, of course, the address field in events should still be there, as it's used
to hold the _reply_ address when the event is delivered. That reply address can
be set to just about anything, but would usually be the address of a port
belonging to the sender of the [request] event.
Unless I mentioned that before: "Request Events" are what I plan to use
instead of the set/get property system used by most plug-in systems. That is,
read/write MIDI controllers. For immediate replies, call process_events() (or
whatever) instead of process() right after sending your request events.
(BTW, process_events() is how plug-in initialization will be handled, as I'd
like to use events all the way through, while a call to process() before init
would be fatal...)
Well, now that I've caused a decent amount of chaos in your minds, I'll get on
with some actual header hacking. :-)
Regards,
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST