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

On Wed, Aug 13, 2014 at 12:08:51AM -0400, Tim E. Real wrote:
 
> Interesting... a pause state.

It's typical for video recorders (and DAT). Software apps wouldn't need one.
 
> With the current system, the user 'presses play button', but the button
> then flashes informing the user it will be a few moments before we're
> actually running, then it stops flashing and system runs.
>
> With your proposal, the 'play' button flashes informing the user the
> system is busy - BUT - at least when it stops flashing, he is /guaranteed/
> that the system will start immediately.

How 'not ready' indicated is a side issue. It could be STOP flashing
when stopped and PLAY flashing if you try to start, or some separate
indication.

> I would add: If play is flashing he shouldn't have to press it again when it
> stops flashing, so let the system remember that he did in fact press play.

The 'not ready' feedback exists to avoid the user trying to start
when it will fail, so this shouldn't happen. But when it does, yes
I'd agree that the start command should be remembered (as in fact
it is now).

Some of the tape machines I used could locate to some stored
position, and while they were doing this you could hit PLAY.
If the fast wind was forward they wouldn't even stop, just slow
down when approaching the locate position to arrive there at the
the correct speed and then go into PLAY. That's nice transport
design.

In software such things are almost trivial to implement, and they
make a difference. Ardour fails here when controlled via OSC. If
you send a 'locate' and then 'play' it will in many cases ignore
the 'play' command. You need to insert a delay between the two
to makes this sequence reliable. This hit me when I was writing
the automated systems used at the CdS, which led me to write a
dedicated player app and think a bit about reliable remote control
protocols.

> Still, to satisfy the OP request, there could be a global record ENABLE,
> while still granting that record ARM is strictly a local thing.
> To rephrase your last sentence could be:
> 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.
 
> > Punch in/out can be controlled
> > locally, and today it will be preprogrammed anyway. [3]
>
> Not sure about global punch in/out. Maybe.

It's never a global thing. One app would do a punch in/out while
the others are just playing. And if not you're doing something
quite complicated, and this will need to be set up and checked
locally on each app anyway.

> How would these decks be told by software to come out of deep-pause mode?

It would be local, or just by sending STOP. And most probably, when
put into remote control mode any 'deep sleep' mode would be disabled.
Anyway for SW apps such a state should not exist at all.

> From the software POV, the play command would have to be sent and
> then we wait for a signal from the deck that it's ready.
> Which is what the slow-sync callback does.
> Seems both it and your proposal would be good to have?

They way I've implemented this in some players uses four states:
all combinations of [STOP, RUN] and [READY, NOTREADY]. A state
that includes NOTREADY is always transient, it will revert to the
corresponding READY one as soon as possible.

The combination RUN, NOTREADY is the one that Jack's 'slow sync'
implements. But it doesn't have STOP, NOTREADY. So that is what
I'd add, together with the requirement that NOTREADY must be
transient, i.e. an app is allowed to be not ready but must always
try to get ready ASAP, and not wait for e.g. a START command to
do so. Being ready of course includes that the audio path is or
can be set up, so things like only creating Jack ports when
started (Audacity) are a definite no-go.

> Pleasure rappin' with ya.
Same here :-)

-- 
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user