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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Mar 4 20:15:02 2012
This archive was generated by hypermail 2.1.8 : Sun Mar 04 2012 - 20:15:02 EET