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

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
> >
> > Mm, no such signal in the Jack Transport API that I know of.
> >
> > But there are Midi commands for such things like play stop record etc,
> > some of which MusE does recognize, but some are waiting to be added.
> > Not sure about the full 'record' family of Midi commands, must check
> > which have been added... I think basic record start and stop are
> > supported.
>
> Ya midi is there, one way or another. Most Applications that support
> recording "something" and jack sync/transport also support punch in/out
> via a midi controler.
>
> MMC is supposed to be real time as well. I do not know the right answer.

MusE does MMC as well.
Partial MTC too, but no actual MTC syncing :-(

> In my case I am making software for a midi control surface, but because
> the "midi" is generated after the signals get into the computer, I am also
> able to use the control surface to control jack transport directly (in
> fact that was easier than sending jack MIDI). From that point of view,
> having a record start would be an ideal global solution. Also, there is
> some software (the non-* group stands out in my mind) that does not have
> MIDI in for control purposes, but reacts to jack transport very nicely.
> 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).

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

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

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)

But then, that's supposed to be the job of the slow-sync callback - holding
 up the transport if necessary. Maybe pass a flag to the callback or something.

And then there's the actual Jack commands to initiate all of this, such as
 jack_transport_record() and/or
 jack_transport_record_arm()

An argument against might be why stop there - let's throw in all kinds of
 other states like punch in/out. But realistically these simple record states
 might be OK. I mean, we have play state already.
So record states seem a logical progression?

Apart from states, other methods of telling the app about record modes
 might include a new 'record' callback or something...

Hope I can get some comments from folks who know more.

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

Again, maybe the new Jack Metadata API is the answer.

> However, I am
> now using either and/or as the user sees fit. One way or another it will
> get done. It seems some controlers just send whatever midi note on is next
> on the table for record enable. However I am less worried about that
> because each key/switch can send a user set midi string/event. I will
> provide some preset ideas that seem useful to me.

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.

Cheers.
Tim.

>
>
> --
> Len Ovens
> www.ovenwerks.net

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Tue Aug 12 08:15:02 2014