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

[Fons Adriaensen]

On Sun, Aug 10, 2014 at 07:11:24PM +0200, Robin Gareus wrote:
 
> It's not that easy.
> Record enable is an application state not a position in time.
> Rec-arm needs to allocate buffers, prepare files on disk etc etc.
> It's not realtime-safe.

That is a weak excuse, and it hides the real reason. Which is
that Jack transport does not require apps using it to remain
ready to run while stopped, nor provides any means for an app
to report 'not ready' until it's too late.

If you need to start 'on cue', which is a rather common thing
in audio engineering, the present system just fails.

Sure, repositioning, creating new tracks or arming some of them
for recording involves things that can't be done instantly and
that are not RT safe. But a few seconds after a well-designed
app is last repositioned or reconfigured it should be ready to
start or go into recording mode instantly. And to make this
useful at all the app should be able to report its readyness
to a shared transport control so that 'one or more not ready'
can be shown to the user somehow (typically done by flashing
the START button).

All that is required is

1. split the 'stopped' state in two: ready or not ready to
   run as configured,

2. require all apps, while stopped, to do whatever it takes
   to get ready ASAP when reconfigured and report 'not ready'
   meanwhile.

I've proposed this a number of times over the last years, it
was ignored each time. (1) is easy enough to implement, (2)
is for application authors, not for the Jack team.

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