[LAD] jack transport change accuracy for looping

[Iain Duncan]

> Can you use the same approach you did in csound, using
> jack_transport's BBT info to run your phasor?  It would require that
> some app set a tempo and time signature, of course.  I use klick, or
> gtklick (which has a tap tempo feature), to do this.
>

That's precisely what I'm trying to figure out right now, and that was one
of things I was looking at jack transport for. In my csound only version,
the master clock was a master 8, ( or 16, or 32 ) bar phasor with modulo
calculations for subloops. so 120 bpm * 32 became the frequency of the
master phasor clock. This was primitive in some ways, but was a happy
surprise musically, as it turned out to be awesome that one could change
loop length and start points willy nilly, if it didn't add up nicely, you
got some truncation on the end but a hard reset at the top of the phasor,
and that *sounded great*. ( Actually that effect is the whole reason I'm
redoing it, it was a super great way to screw with loops and when I got
demo'd Live, I was like, ok we gotta do this with that cool phasor
technique again ).

Where my brain is hurting right now is making the jump between the way I
though about it Csound, and the putting in to buffer callbacks in Jack ( or
RTAudio or PortAudio for that matter ).

What I do know, is that if I'm using Jack, I might as well make sure that
the 8 bar phasor is using the exact same version of '8 bars' as jack
transport.

I suppose one option is to do it STK style and just treat it like single
sample calculations until I get some draft thing running and revisit later.

Any suggestions welcome, I can see doing the math on running counts of
individual samples, or doing it on time taken from the jack transport
clock. Not sure which to try first,

thanks for the input!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20111120/4f78a00d/attachment.html>