[LAD] jack transport change accuracy for looping
pcoccoli at gmail.com
Wed Nov 23 13:17:30 UTC 2011
On Sun, Nov 20, 2011 at 12:23 PM, Iain Duncan <iainduncanlists at gmail.com> wrote:
>> 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 ).
Create a buffer with the same length as the jack frame size, and the
first thing you do in your jack callback is use jack_position_t to do
the computation of how many frames make up one cycle of your phasor.
Based on the BBT info in jack_position_t, determine what "phase" of
your phasor to start with, and fill the buffer. Then you can use that
buffer to drive your loop playback, create oscillators, etc.
> 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
Yes, exactly. You can do this using the jack_position_t info.
> 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!
More information about the Linux-audio-dev