Transport proposal

[Fons Adriaensen-2]

Proposal for simple extension of Jack Transport
-----------------------------------------------

The current transport design does not allow to
verify if all clients are ready to start (go to
the Rolling state) immediately, without actually
trying to start them.

In fact it allows clients to ignore any locate
commands while in Stopped state, and only locate
when they actually have to start, at which time
it's probably too late and they have to delay the
start.

IMHO clients should always execute locate commands
immediately even in the Stopped state (and e.g.
Ardour does so), if only to get the correct initial
automation state, or more generally, to initilaise
the complete session state (e.g. MIDI presets and
controller values) corresponding to the new position.

Doing this would allow most of them to start without
delay, a short time after the last locate while Stopped.
Probably many clients just operate that way. But there
is no way to detect if they are actually ready or not.

One solution could be quite simple:

1. Add a new state, 'JackTransportLocating'
2. When jack_transport_locate() called while Stopped,
   the new transport state becomes 'Locating', the sync
   callbacks are called until all indicate ready, then
   then state reverts to Stopped.
3. Stop or Start while in 'Locating' or 'Starting' just
   switch to their corresponding transient state.

The effect is that 'Stopped' actually means that
all are ready to start without delay. Apps using
the sync callback would be expected to be designed
in a way that actually ensures that this is true.

This solution is not 100% complete. There is a silent
assumption in this scenario: that having to relocate
is the only reason why an app could ever be not ready
to start. It does not deal with apps that have separate
"Stop" (not ready) and "Pause" (ready) states.
An app could also become not ready to start for a short
time for other reasons, e.g. being switched to record
mode and having to open files. It could even be not
ready for any lenght of time if not set up correctly,
etc.

Dealing with all this would require more invasive
changes.

--
FA


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Gabriel M. Beddingfield]

Hi Fons,

On Fri, 23 Oct 2009, fons@... wrote:

> The current transport design does not allow to
> verify if all clients are ready to start (go to
> the Rolling state) immediately, without actually
> trying to start them.

It sounds like this proposal only covers going from Stopped to Rolling.
Is that correct?

What's a typical use-case where this functionality would be helpful?

Also, by "immediately" do you mean "on the next process() cycle"?
(Whereas reposition() is in 2 process() cycles without any slow-sync
clients.)

Thanks,
Gabriel
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Fri, Oct 23, 2009 at 11:18:29AM -0500, Gabriel M. Beddingfield wrote:

> >The current transport design does not allow to
> >verify if all clients are ready to start (go to
> >the Rolling state) immediately, without actually
> >trying to start them.
>
> It sounds like this proposal only covers going from Stopped to
> Rolling. Is that correct?

Did you actually read it ???

The current implementation supports apps reporting not-ready
and delaying the transition to Rolling.

The proposal would allow client to report not-ready while
relocating also while stopped.
 
It's just essential feedback to the user.

Set your CD player in "Pause" (i.e. ready to start
with the disc rotating). Locate to a different track.
Typically the display will flash, show something
rotating, or indicate in some way that the player
is locating, which could take a second or so if you
go to the other end of the disk. When the display
reverts to normal you know you can start immediately.

Most software apps provide a similar indication if
they can't locate instantly. The indication will be
either explicit (similar to the CD player), or other-
wise it will be clear somehow by looking at the GUI
if the app has reached the new position or is still
working to get there. As a user you expect this
feedback.

The problem is that the same information is not
available if an app is controlled via Jack transport.
An GUI which has jack transport controls (e.g. qjackctl)
has no information to show the 'seeking' state.

This is nuisance for human users, but it gets worse
if the transport is controlled by software without
any human looking at it.

> Also, by "immediately" do you mean "on the next process() cycle"?
> (Whereas reposition() is in 2 process() cycles without any slow-sync
> clients.)

By "immediately" I mean "without any delay added by clients
and reported via the sync callback.

Ciao,

--
FA
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Gabriel M. Beddingfield]

Hi Fons,

On Fri, 23 Oct 2009, fons@... wrote:

>> It sounds like this proposal only covers going from Stopped to
>> Rolling. Is that correct?
>
> Did you actually read it ???

Of course!  2 or 3 times before asking.  2 more after. :-)

> The proposal would allow client to report not-ready while
> relocating also while stopped.

Soooo... yes? :-)

OK, I think I understand your proposal now.

Thanks!

-gabriel

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Please create a ticket : http://trac.jackaudio.org/report

Thanks

Stéphane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org