Hi, as you may know I'm the author of simsam (http://simsam.sf.net) and I'm a little stuck with some typical audio application design problems. So far I've been using an Observer pattern to have the GUI updated as soon as a parameter changes. Thus any operation setting a parameter can trigger one or several Widgets to be redrawn. Since so far I only set parameters from the GUI thread, the resulting GUI updates also run in the GUI thread, so no problem there. One problem however is that access to the parameters isn't synchronized and therefore concurrency problems exist. The same problem exists between MIDI and audio thread, as MIDI events are currently handled entirely in the MIDI thread. The obvious answer is to use mutexes to synchronize the parameters, but then of course they aren't rt-safe. The next obvious answer would be to use a lock free FIFO. I've seen some code passing MIDI events to an audio thread that way. Thus the state is only maintained in the audio thread. But what about GUI events? And GUI callbacks? Surely one doesn't want the audio thread to execute widget redraws. So one has to de-couple these mechanisms, for example by defining event and update messages and passing those around by FIFOs instead of direct parameter manipulation / direct GUI callbacks. Now this would totally break my app and I would therefore like to hear some thoughts on the whole issue before I start messing things up (even worse ;-P). Thanks Christian Henz