3 Nov
2016
3 Nov
'16
7:47 p.m.
On Thu, 3 Nov 2016, Rui Nuno Capela wrote:
a) there's no OSC control interface on qtractor
"master" branch; only
good old and genuine MIDI, regular 7bit channel messages (eg. CC, but
any other message will do) and extended 14-bit channel too, (N)RPN and
CC14 pairings; user configurable PC-keyboard shortcuts are also in place
as well;
b) there's an experimental OSC infrastructure also in place for too many
some years now, rather specific interface to freewheeling [1], which
lives under the "oscx" branch.
For transport control and even banked channel control with known controls,
Midi works very well. The main place OSC can do more is with changing sets
of controls where the controller wants to know what the DAW (or other SW)
has. Notice the word "can" most DAWs and controllers really don't do much
more than could be done with MIDI. I am really interested in something
more like OCA http://ocaalliance.com/technology/specifications/ where one
controller can ask several devices what controls they have and create a
control interface that can control all of them. It uses similar ideas to
EuCon. There are other control types too, but all of these OSC, OCA,
EUcon, etc. use a path type idea for each control. Each path is a c++
obect and deeper paths are sub or sub/sub objects. The OSC lib (well liblo
anyway) does not force this on people (or help them implement it either)
and so many OSC implementations end up out of order:
/track/fader/<ch #> value rather than /track/<ch#>/fader value because
liblo does make parsing /path rather easy, but not /part/* so much. So it
is easy to do /path with a number of parameters rather than use path with
embedded parameters. (Ardour uses both)
I have spent too much time on daw control this past year...
--
Len Ovens
www.ovenwerks.net