Having just implemented seamless looping in ardour, I find myself wanting a way to use this in conjunction with the jack transport system. This has been touched upon in the past, so here is my proposal for extension: Reintroduce two new items into jack_position_t's padding space:
jack_nframes_t loop_start;
jack_nframes_t loop_end;
Introduce a new api call:
jack_transport_start_loop()
which will do exactly the same thing as jack_transport_start except the state (after slow-sync procedure) will be JackTransportLooping? (already defined).
jack_transport_reposition() will be used as-is to set/modify the loop boundaries, and proper slow-sync procedure is still used whenever loop bounds change while JackTransportLooping?.
The key element of the JackTransportLooping? state is that jack will wrap the frame position appropriately after the cycle containing or ending on the loop_end. All clients who can handle the looping state will already be aware of the loop boundary from their last slow-sync at reposition/start and are expected to have already made preparations for the seamless wraparound.
On the last cycle in a given loop, the starting frame will be correct, but due to the loop_end, the effective transport frame after the loop_end within the cycle will wrap to loop_start -- all clients are expected to handle this intra-cycle mod-arithmetic internally. Jack will apply the proper mod-math at the start of the next cycle.
The only issue i foresee is with clients who support the jack transport but do not know about the JackTransportLooping? state. Depending on their implementation, their results could be unpredictable. If they are simple (fast-sync) clients, most likely they will just run past the loop_end in the last cycle, only to be corrected at the start of the next cycle. If they are slow-sync, well... they could quite easily become confused, or they might ignore the looping altogether.....
Anyway, as you can see, the jack-side implementation of this is next to trivial. Most of the onus is upon the clients to make jack-wide seamless looping a workable reality.
State transitions are as follows.
* JackTransportStopped
-> jack_transport_start_loop()
ifloop bounds legal then normal sync
operation follows.....
* JackTransportStarting
* JackTransportLooping
--------------------------------------
* JackTransportLooping
-> jack_transport_stop()
* JackTransportStopped
-------------------------------------
* JackTransportLooping
-> jack_transport_reposition()
loop bounds legal (start must be strictly less than end),
normal sync operations follow:
* JackTransportStarting
* JackTransportLooping
-------------------------------------
* JackTransportLooping
-> jack_transport_reposition()
but loop bounds are *illegal* (start must be strictly less than end).
* JackTransportStopped
[instead of stopping, we could also transition into rolling]
--------------------------------------
* JackTransportLooping
-> jack_transport_start()
normal sync operations follow:
* JackTransportStarting
* JackTransportRolling
--------------------------------------
* JackTransportRolling
-> jack_transport_start_loop()
if loop bounds are legal, normal sync operations follow:
* JackTransportStarting
* JackTransportLooping
This thanks to David's mail archives - even more discussion at http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2010-January/004381.html
