[LAU] Jack transport - was - Ardour/Muse Jack tempo lock

[Len Ovens]

On Wed, 13 Aug 2014, Fons Adriaensen wrote:

> On Wed, Aug 13, 2014 at 12:08:51AM -0400, Tim E. Real wrote:
>> Those that have local RECORD ARM enabled will record when started,
>>  provided global record ENABLE is on.
>
> That assumes that all apps have per-track record enables. A simple
> stereo recorder/player won't have them.
>
> Anyway, to set up recording you'd have to access the local user
> interface of that app, so having to enable record there is no big
> deal. To me it also feels safer.

To be honest, the reason I thought it would be nice is because I was 
looking at an app with no MIDI control in, but does have jack transport 
control. I was thinking that a master record enable was the one thing 
that traditional tape transports control clusters had that was missing. Of 
course just because it is traditional is not a great case for including 
it. On a tape machine all the controls are clustered for other reasons and 
the record arm sometimes does have more space around it or is sunken or 
has ridges on its sides.

Having said that, most control surfaces that include a transport section 
and for that matter, most sw that has a transport section laid out in the 
gui, has the record enable included in that group. So it is a tradition 
that is still in common use. What would be called a defacto standard or a 
standard by tradition. Again I don't know if it is a good standard or not 
but that is where the hand of a recording machine operator will look for 
the record button.

The next question is if a control surface should directly control jack 
transport. I think the answer is that enough people think is should that 
there are a number of standalone jack transport controlers around. Really 
the only thing missing is the record functionallity to be complete. 
Nudging and shuttling are already easy to do... I suppose scrubbing, or 
playing back at non-standard speed is not there, but I am not sure how 
that would be done and for now at least, this is not a universal thing 
that SW does, so most apps would ignore it anyway. A state that says make 
noise even if we are not in play, but we move the transport?

The whole thing comes down to sync and the purpose behind it. This is much 
more common in Linux than other places because we can. The purpose is to 
take a number of applications and perhaps physical playback/record devices 
and to use them all as if they were one machine. From that POV, a single 
transport control makes sense. From that POV, using one control surface 
for more than one application/device also makes sense. I would suggest, 
however, that this practice is becoming less common as applications add 
more functions and become more "all in one". It seems that audio recorders 
now edit MIDI (and have instrument plugins) and MIDI editors record and 
playback sound. Even video can be included. When I first started doing 
music on computers, recording audio on a computer was just a dream. MIDI 
was no problem (if you stayed away from windows) and so audio was recorded 
on a tape machine and the computer sequencer followed the timecode 
stripped on track 8 (permanently set to record at -10db for this purpose). 
Sync was the only way to get enough tracks for many things. Not any more.

Just to be complete... I have looked at OSC. OSC is very flexable. 
However, that flexability seems to be it's problem too. There is no way to 
create a generic control surface with /softwarename/track1/gain and then 
go "bank up/right" and have the mapping change to 
/softwarename/track9/gain within the software... no standards for this. To 
be fair, there was not in MIDI either till people started making control 
surfaces and the software had to deal with whatever they put out and that 
became the standard (The mackie control protcol for example). However, as 
a contol surface manufacture, why would I make an OSC product? What market 
share would that gain me? Really, in order to even create a middleware 
converter from MIDI controller to OSC would be a pain. I would have to do 
all the banking in that middleware. I would have to know all the strip 
names (takeing non-mixer as an example 
"/strip/stripname/pluginname/paramname param") and map them to a number... 
or name them in an unituitive manner in the first place. Ardour uses 
something totally different "/apname/route/function tracknumber param". 
The ardour method at least could be banked reliably. I suppose a patch bay 
kind of middleware that showed controler outputs and SW inputs for control 
could work, but it seems poor to have a user patch what would be normal 
routing for each project. OSC has a way to go, IMO, it is not ready to use 
with control surfaces.



--
Len Ovens
www.ovenwerks.net