On Sat, Nov 19, 2011 at 10:23 PM, Iain Duncan <iainduncanlists(a)gmail.com> wrote:
Thanks, I know you did some stuff with this with your
old step sequencer. Do
SoftWerk? It didn't use JACK at all because when I wrote it
(pre-Ardour, pre-JACK) there was no JACK MIDI and no point in using
it. One day I might do a JACK MIDI version. Or an LV2 version. Or ...
you think it's better to just ignore moving around
the jack transport and do
my looping internally to my app only? If there are known issues that I'm
just going to discover the hard ware, might as well save time not barking up
the wrong tree.
i think you may be confused about what JACK transport offers. its a
global transport. that means that when you locate (which includes to
looping) to a new position, *all* clients must be ready to continue
processing audio before it can roll again after the locate. For some
kinds of clients, the transport is totally irrelevant (e.g. a software
synthesizer). For other clients, they can be ready immediately that
the locate happens (e.g. a MIDI sequencer running instrument plugins).
For other clients, there is a delay between the locate and them being
ready to play because of the need to load any amount of data from disk
(imagine locating to a new position in a 100 track session in a DAW).
now, if the clients all knew that (a) JACK transport was in a looping
state (b) where the loop points were, they could prepare for this, and
everyone could be ready immediately after the locate. Ardour can
already do this without JACK, for example (its called "Seamless
looping" in ardour, and rather than actually locate and then do the
data i/o, it understands ahead of time the the loop point is coming up
and gets the next chunk of data from the right place).
however, JACK currently does not have a mechanism to mark the
transport state as "looping" or to convey the loop points to clients.
that's why in Ardour, for example, seamless looping is not allowed if
you are synced to JACK transport (or MTC or MIDI clock or ...)