<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">i think you may be confused about what JACK transport offers. its a<br>
global transport. that means that when you locate (which includes to<br>
looping) to a new position, *all* clients must be ready to continue<br>
processing audio before it can roll again after the locate. For some<br>
kinds of clients, the transport is totally irrelevant (e.g. a software<br>
synthesizer). For other clients, they can be ready immediately that<br>
the locate happens (e.g. a MIDI sequencer running instrument plugins).<br>
For other clients, there is a delay between the locate and them being<br>
ready to play because of the need to load any amount of data from disk<br>
(imagine locating to a new position in a 100 track session in a DAW).<br>
<br>
now, if the clients all knew that (a) JACK transport was in a looping<br>
state (b) where the loop points were, they could prepare for this, and<br>
everyone could be ready immediately after the locate. Ardour can<br>
already do this without JACK, for example (its called "Seamless<br>
looping" in ardour, and rather than actually locate and then do the<br>
data i/o, it understands ahead of time the the loop point is coming up<br>
and gets the next chunk of data from the right place).<br>
<br>
however, JACK currently does not have a mechanism to mark the<br>
transport state as "looping" or to convey the loop points to clients.<br>
that's why in Ardour, for example, seamless looping is not allowed if<br>
you are synced to JACK transport (or MTC or MIDI clock or ...)<br></blockquote><div><br></div><div>Thanks, that clarifies things a lot for me. I didn't think about the disk seeking issue. (For my app, my intent is to have everything in RAM for live playing ). Was the intent of the jack looping transport proposal to allow clients to know that they were looping and do seamless looping too if they are able?</div>
<div><br></div><div>iain </div></div><br>