On Sun, 2012-03-04 at 14:14 +0100, Albert Graef wrote: > On 03/04/2012 03:47 AM, David Robillard wrote: > > I probably said this. Internally it's like Jack in most of the > > important places, i.e. the actual type of the event payload is pretty > > much irrelevant. The biggest problem to solve is the on-disk format. > > That shouldn't be a real problem. OSC is already serialized after all, > and uses network byte order. So you can just take those blobs and save > them to a file and read them back again.
I would assume that any realtime local transport via something like Jack or plugins would eschew the network byte order thing since that's quite a massive amount of overhead for no reason. You'd have to to actually send it over a network protocol or disk though, of course. Sure, given that you already have a POD serialization, inventing such a format wouldn't be hard. Perhaps just invent a RIFF chunk for them. Time stamps may be a question for sample accuracy. > > Control data (i.e. "automation") in Ardour is its own thing, not even > > really MIDI related. I co-opted the existing automation system as much > > as possible deliberately for this reason. It could be made to *send* > > OSC messages for curves pretty easily. > > If it can be made to also record OSC messages and if I can pick the OSC > addresses that I want What do you mean by "pick the OSC addresses that I want"? -dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
