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

On Mon, Aug 11, 2014 at 08:01:40PM -0400, Tim E. Real wrote:
 
> Mm, do you know about the 'slow-sync' Jack callback function?

Of course I do. Do you really think I'd comment on anything without
knowing it inside out ? That very 'feature' is the problem.

> Or do you propose something slightly different?
> As in, able to report readiness anytime all the time even in stop mode?

Yes. Together with the requirement that any app using the transport API
should be ready to start running (playback and/or recording previously
armed tracks) instantly a reasonable time (at most a few seconds) after it
has been repositioned or reconfigured. Or at least have a state - PAUSE -
in which this is the case [1].

In fact any app used for audio recording or playback in a production
context should have that property even when used separately, without
Jack transport. All professional audio or video equipment I've ever
used could do that, even in the tape days [2]. It's a rather basic
requirement, and not at all difficult to implement.

In other words, the not-ready state should be transient, it will
revert to ready ASAP, and it serves mainly as a warning to the user.
As soon as everybody reports ready, you know you can start instantly,
which is very reassuring in a live context.

> The 'slow-sync' Jack callback function is a great feature for
> holding up the transport until all the apps report they are
> 'ready to roll'.

To be able to start 'on cue' they must be ready when the start
command arrives and NOT delay it. Starting on cue is a very
common thing in broadcasting, theatre sound, live shows, audio
drama production,... to name just the few cases I've encountered
in my work.

> But... not ready for what? The app cannot know what the
> next transport intention is until the actual command
> comes down the line.

Ready to do what would be required 'on cue', i.e. playback.
Recording on pre-armed tracks is no more difficult, so I'd
include that as well. All the rest (repositioning, preparing
to record) can take any time you want, nobody expects that
to be 'instant'.

I don't think that a global RECORD command or state should
be part of a shared transport control, it's local thing for
each of the controlled items. Those that have RECORD enabled
will record when started. Punch in/out can be controlled
locally, and today it will be preprogrammed anyway. [3]

Caio,

[1] Video tape recorders used to have a separate PAUSE state
since leaving the tape static against the rotating drum for
too long would damage it. Audio tape recorders usually did
not have a separate PAUSE state, they could start instantly
from STOP.

[2] I know of one professional tape recorder that would spin down
the capstan when idle for more than a few minutes. But even that
one would warn you a few seconds before doing that, and hitting
STOP would override the spindown and keep the transport ready to
start instantly.

[3] In the 24-track tape days punch in/out could be done either
by pre-arming the required tracks and then using the global RECORD
at the right time(s), or by starting with RECORD enabled and then
using the per-track controls to punch in and out. The latter would
be difficult in a software DAW, unless the tracks are prepared in
some way previously (which happens implicitly when using the first
method). But it's not really required, the first method works OK,
even more so if things can be pre-programmed as in Ardour.

-- 
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