On Sun, 2012-03-04 at 00:55 +0100, Albert Graef 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.
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.
It would be nice if this integrated with stuff in the plugin sphere, but
I've come to the conclusion that, unfortunately, OSC is more trouble
than it's worth there (though nothing is stopping anyone from using it).
After countless attempts at achieving a decent more-powerful-than-MIDI
mechanism, I've come to this opinion:
Give me a simple data model based on primitives, lists, and dictionaries
any day over some clunky command-like message format.
To me, the easy integration that gives you (with e.g. the dictionary
built in to pretty much every programming language ever, Turtle, JSON
(and thus webby everything), key:value stores), the 'meaningfulness', a
standard string serialisation, and an easy ability to describe
arbitrarily complex things via nesting, is of infinitely more value than
integrating with the tiny nichey collection of things that support OSC.
Maybe it's just that I've tried to do some pretty advanced things on top
of OSC (like 100% of GUI<=>engine control), but it's just a little too
half-assed for my tastes these days.
That said, I'm fully behind anything that would provide the individual
note control and high controller precision that MIDI can't.
Linux-audio-dev mailing list