Synching two ~grooves with different lengths: the wrong kind of drifting...
This is my 3rd start at a steve reich-y phase looper (last version used tapin~ instead, but was click-heavy)
Basic idea is to be able to record loops that are proportional in length to a first, master loop. So you can record an arpeggio of 4 notes in one groove~ and 3 notes in the other, and they will phase - but still sync up every 12 notes. So the timing needs to be very precise.
This (see patch) is the only way I can think to do it, but it's drifting quite quickly, and by quite a large amount. (Which is very steve reich too I suppose - but I need precision right now....)
Any ideas why it's so inaccurate? And what direction to take next?
Thanks senior types, appreciate any advice you have.
Lee
This is quick and hacky, but should get you closer:
(If you want things absolutely locked in, I'd look at wave~, rate~ and phasor~ for playback)
Round! Float-flavour Round!That's a great idea. I am really grateful (again).
I'm still struggling to get fully to grips with signal-driven stuff - accurate though wave~ and phasor~ may be, so this maths solution is really clear. Thanks Peter.
Glad to help. Also: forgot to mention, but you could use trapezoid~ instead of the pong~/clip~ bit. Or... a while back on the forum I posted a groove~ written in gen~ that could be restarted sample-accurately and also had a fade in/out that could be specified in ms. (so it didn't get too long as your loops get longer)
For the timing stuff, you can think of the round bit as the derivative case of:
loop2_time / loop1_time
|
maximum 1. (if you want to make sure that the second loop isn't smaller than the first; the other case is doable, just more of a pain)
|
round (or other function--could "round" to nearest power of two, etc.)
|
* loop1_time
(be sure to provide a floating point argument for all math objects here or you'll get drift due to truncation in the math)
One other thing I just realized: you probably don't want to stop recording on buffer2 when the record toggle is switched off. It's better to fade out record~'s input and write zeroes to the end of the buffer, since the played back length could exceed the recorded length (and that would mean you might play some previous input at the end)
I would anticipate that the thing I posted is still subject to drift, but it should be much slower.
Sure, it's this one:
https://cycling74.com/forums/gen-sample-playback-retrigger/