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

[Len Ovens]

On Mon, 11 Aug 2014, Tim E. Real wrote:

> On August 11, 2014 07:21:17 PM you wrote:
>> On Sun, 10 Aug 2014, Tim E. Real wrote:
>>> On August 10, 2014 09:24:12 AM Len Ovens wrote:
>>>> Is there a record enable in there? It seems to me it would be worthwhile
>> One of the sub projects of this software is to split the computer keyboard
>> so that the numeric keypad can be used as a midi/jacktransport control
>> surface while the rest works as the system keyboard still, so I have an
>> interest in a more complete jack transport from that POV.
>
> Hmm ...
>
> The only way I could see this in terms of the Jack Transport 'states'
> is to add some new states:
>
> For example:
> JackTransportRecordArm (maybe to help prepare)
> JackTransportRecordEnable (subsequent play mode actually means record mode).

MMC, from what I have read, seems to support two record enables:

  - arm tracks for recording. While these are in the realtime section of 
commands, I would think these would be the commands run before roll to 
give sw time to get things ready to record.
  - Then there is punchin/out or master recordenable which is meant to be 
realtime and should start the app recording with no transport stumble or 
wait.

Now maybe there are people who think using track-rec-enable for 
punchin/out is the way to go, but I can't see myself working that way. I 
also do not think it would be the right thing to do, to expect jack 
transport (or any other transport) to arm tracks of multiple apps... or 
even one app, because this would assume a static number of tracks. The 
punch in/out master rec-enable does make sense though. all the enabled 
tracks would record at the same time.

> But those do not qualify as 'states', they are just commands !

Yup.
>
> So we might propose something like:
> JackTransportRecording (in actual recording state)

Ok, I, in my limited POV, don't see a need for this unless one of the apps 
fails to start recording and wants to signal this somehow.
>
> But then we might also need something like:
> JackTransportRecordStarting (so that the app can differentiate between
> play starting and record starting modes, and tell Jack Transport to wait)

IMO, they are the same thing. When getting ready to play, anything that 
needs to be ready for record should be done too. The transport can not 
wait at the punch in point for sw to get ready or else the whole punch in 
concept is void. Any sw that has a track recenabled should be making sure 
it is ready to record on those tracks before playing. It _may_ be OK for 
an app to start recording some ms late provided the actual time of the 
record starting is saved as the punchin point for that app... this gets 
messy real quick though.

If there is to be any "get ready time" at the record strobe, the play 
state must not change once started just for recording sake, better a 
system wide record start delay of the punch in point.

I still feel the app should be ready to record anywhere from the play 
start with no delay.

> Obviously difficult to ensure compatibility with existing apps, I suppose...

I would expect an old app to ignore it (them, punch in and out) and lets 
get fancy and ask for the moon... jack transport would of course drop in a 
MIDI port for telling these old apps to start recording  :D

> In MusE you can map any midi note to any of the transport functions :-)
> For example hit a high 'C' and it starts playing.
> It has mappable Stop, Record, Goto Left Marker, Play, and Step functions.

With the variety of MIDI control surfaces around, one pretty much has to.

And now having gotten my feet wet with jack midi stuff... I am thinking of 
a MIDI control surface mapping app that takes MIDI in from a control 
surface and splits it for a number of applications. The idea being that a 
controller that has 8 channels and does banks, might send controls for 
bank 1 and 2 to one app and bank 3 to a second and maybe bank 4 to a 
third. While it may be possible to auto figure out how many banks each app 
has, the operator might be better for settng it up and knowing what is 
what. Of course as apps become more "do everything" the use for such a 
thing may be waning.

I have looked at OSC... but it has no standards (bad way of trying to 
make my point), each signal seems to have 
to be directed at a particular app/control. There seems to be no generic 
controls where a generic control surface can be used. Maybe that is 
because all the docs I have read are showing off it's flexablity. It seems 
even a native OSC control surface would need middleware to rename the 
signal so the destination was correctly chosen.

--
Len Ovens
www.ovenwerks.net