Perturbations in playback rate with irrational numbers

I’ve made a granulator for my patch.init() that captures incoming audio gated with an envelope follower. Audio is sliced and recorded into 8 different channels of a buffer. The grains loop and rise/fall over a long global envelope. I use a second buffer to store different rates for an accumulator to pitch-shift the grains as they play back. Nothing extraordinary.

However, certain playback rates are affected by unusual drifting of pitch at moments in longer envelopes. Shifting up 11 semitones (1.875), up 4 semitones, (1.25), and up or down an octave or two (2, .5, .25) or other rational numbers do just fine. It’s the shifting down 7 semitones (.666) or down 19 semitones (.333) that cause the strange drifting. These values are stored in a buffer that’s initiated on startup (see video). I’ve tried expressing them with various degrees of precision or using fractions. Still, the weird drifting persists for the “irrational-ish”(?) numbers no matter what.

I’ve tried putting this patch on my Daisy submodule in the Patch.Init() as well as my Daisy Patch. Same result. I’ve tried fast math on and off for both. I’ve tried flashing with the debugger. But when running my patch in gen~ on the computer, I don’t have these problems. I’ve really tried to dig into this but can’t figure it out.

I performed with this patch the other night (which I call “Arvo,” because I use it with my violin and can get some evocative results), but I was using shorter envelopes so I didn’t notice the problem. It only seems to happen over the course of longer envelopes, as you can hear in the video (starting at 1:07) when I switch to the second channel of the buffer for playback rates 1, .666, and .5.

video of pitch perturbations on patch.Init()

Hey Seth!

I would love to see more of the patcher.

Also, there was a forum question last week where a user was having issue using [counter] and (I’m guessing) [peek] operator to change a pitch of a looper in Daisy. I suggested the [phasor] & [sample] approach, and they seem to be cool with that approach when I answered the same question on Discord.

More detail here: Counter and playback

I suggest trying that out and see if it helps! I recently converted from the [counter] or [accum] & [peek] approach to the [phasor] & [sample] approach :slight_smile:

Hi Takumi!

Thanks, you’re correct, this is a [accum] + [peek] situation. I’ll reimplement and test in the way you suggest. Here’s what an “Arvo” voice currently looks like:

1 Like

Yep, problem solved, no more weird pitch stuff. Thanks for the tip, Takumi! Here’s the updated “Arvo” voice using [phasor] and [sample] instead of [accum] and [peek]:

1 Like

Nice!! I’m glad to hear that worked. It seems that Daisy likes this approach more probably due to the buffer size being out of the equation?

Please keep us posted on the project! Looking forward to it :slight_smile: