4 Mar
2012
4 Mar
'12
6:32 p.m.
On Sun, 2012-03-04 at 14:14 +0100, Albert Graef wrote:
What do you mean by "pick the OSC addresses that I want"?
-dr
On 03/04/2012 03:47 AM, David Robillard wrote:
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.
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. 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