On Sun, Nov 20, 2011 at 12:23 PM, Iain Duncan <[email protected]> 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 ).
Sounds reasonable. > 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 > 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 > 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
