linuxaudio.org

On Sun, Nov 20, 2011 at 12:23 PM, Iain Duncan  wrote:

quoted text
>

>> 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 ).

Sounds reasonable.
> Where my brain is hurting right now is making the jump between the way I

quoted text
> 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

quoted text
> the 8 bar phasor is using the exact same version of '8 bars' as jack

> transport.

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

quoted text
> 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!

>

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev