On Thu, 2011-11-03 at 09:39 -0400, Paul Davis wrote: > On Thu, Nov 3, 2011 at 9:22 AM, Harry van Haaren <[email protected]> > wrote: > > On Wed, Nov 2, 2011 at 5:09 PM, Iain Duncan <[email protected]> > > wrote: > >> > >> I'm hoping to arrive at some sort of design that ultimately lets the > >> engine act as an audio server with multiple user interface clients, > >> possibly > >> not even on the same machines > > > > Did you concider using OSC as an "abstraction layer" between your GUI & > > Engine? Spares quite a lot of nasty shared-mem tricks, and RCU, well.. is > > suppose you could have the editing commands sent to engine, or else run the > > algo on the GUI side, and update the sequence in the engine. > > no, using a protocol like OSC doesn't solve the basic problem: making > changes to data structures used by the RT code when those changes > can't be done with RT constraints (e.g. memory allocation). you still > need some code that runs outside RT constraints to modify the data > before giving the new version to the RT code to use.
True, though it's a good idea regardless if it's feasible. If you're going to go cross-language anyway, you might as well put a real protocol in-between so you gain the advantage of being able to do separate processes/machines as well. IMO sending "commands" between UI and engine is the best architecture for things like this anyway, which lends itself easily to using an actual protocol. -dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
