On Fri, Mar 22, 2013 at 2:58 PM, Frank Kober <goemusic(a)yahoo.fr> wrote:
it didn't work for me. Maybe I'm wrong but if I understood correctly,
recent jack1 transport no longer goes into Jack_Transport_Starting state
before going to Jack_Transport_Rolling (this was deliberately dropped), but
seq24 currently needs this to start off with jack transport.
what leads you to make this claim?
nothing has been changed in jack1 transport in a VERY LONG time.
http://jackaudio.org/files/docs/html/transport-design.html
the docs say:
The engine handles polling of slow-sync clients. When someone calls
jack_transport_start()<http://jackaudio.org/files/docs/html/group__Trans…af>,
the engine resets the poll bits and changes to a new state,
JackTransportStarting<http://jackaudio.org/files/docs/html/transport_8h.…ac>.
The *sync_callback* function for each slow-sync client will be invoked in
the JACK process thread while the transport is starting. If it has not
already done so, the client needs to initiate a seek to reach the starting
position. The *sync_callback* returns false until the seek completes and
the client is ready to play. When all slow-sync clients are ready, the
state changes to
JackTransportRolling<http://jackaudio.org/files/docs/html/transport_8h.h…
.
and also:
These request a new transport position. They can be called at any time
by any client. Even the timebase master must use them. If the request is
valid, it goes into effect in two process cycles. If there are slow-sync
clients and the transport is already rolling, it will enter the
JackTransportStarting<http://jackaudio.org/files/docs/html/transport_8h.…
and begin invoking their
*sync_callbacks* until ready.