[LAU] Qtractor - & friends - ONE WINDOW setup!!

Len Ovens len at ovenwerks.net
Thu Nov 3 18:47:05 UTC 2016


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



More information about the Linux-audio-user mailing list