Cheers for the link, I've browsed it before I think, consider yourself "blog-famous" :D

 Indeed the functor system will work, but I find the syntax quite clumsy, and I don't want the GUI to become non-responsive until the Engine signals the event is done. Reason for this is that there's quite an amount of events going back and forth, and I estimate the GUI will become too laggy to feel right.

While I could do some (nasty) event checking and not in general, only blocking when I know I'm changing the state of an EngineElement that I need a reference to. Again quite nasty IMO. The other problem is that since all communication is OSC, I cannot guarantee that all "controller" or "view" programs (ie OSC senders / receivers) will comply. So I need a "foolproof" plan, where *any* messages can be sent in *any* order, without crashing / hiccups.

Your mention of "poor man's garbage collection" is quite a do-able system, and I like how it automatically abstracts the non-RT actions away from the RT thread. (ie: removing samples from mem etc) Will let you know if I ever get around to doing it... Currently I'm just storing all samples ever used in mem... and praying somebody doesn't load a 2GB .wav file :D

<http://www.codeproject.com/KB/cpp/fastdelegate2.aspx>  for example.
(I used Don's original "Fastest Possible C++ Delegates" on an embedded
project years ago -- worked great).