30 May
2003
30 May
'03
11:07 a.m.
I am trying to implement a (hopefully:-) ) simple
general-purpose event
delegation architecture.
The actual application will propably be something like a network of
modules that can do arbitrary filtering, generation and manipulation of
midi events in real time.
As propably different kinds of external event sources, like several midi
ports, maybe joystick device and of course a gui, are involved, how
would one efficiently organize the delegation of events passed between
the modules, so that the everything is still thread-safe?
The three main ideas i can currently think of are:
interesting you should ask. in ardour, i have recently been shifting
from a rather complex model toward a very simple one. ardour has
several event sources (automation, GUI, MIDI, audio). there used to be
two different approaches to processing an event:
a) code to handle it is part of an object, and can be called
by any thread.
b) code to handle it is part of an object, but must be called
by a specific thread.
events in class (b) would be queued (lock-free) where they would wait
to be processed by the relevant thread. events in class (a) would get
handled immediately by whichever thread received/noticed the event.
slowly, but with all the certainty of a rising tide, everything is
shifting to a model in which more and more events are queued (lock
free) for the main audio thread, and all events are processed in FIFO
order by that thread.
the complications that i've discovered from attempting to have
different threads handle things without using locks are just to
signficant to be worth the effort (at least at this point).
in addition, lots of event processing in ardour consists of setting a
"desired" value for various things; the real-time code is responsible
for interpolating between the current value and the "desired"
value. you can imagine, i trust, that this can get quite complicated :)
--p