Here's a patch that lets you sync up one groove~ to another and gives a sample accurate trigger for any other bits of your patch that might need it:

Regards jan.

I've used it to create triggers for the end of playback. And I also recall using it to drive an amplitude windowing function. (Although with groove~'s interpolation function, I'm not quite sure why I would have needed to do that.)

Hello Jan, thank you very much.

Your patch works very nicely. Now my problem is: I don't understand why. i tried changing the values in both the change as well as the delta variant, i can't figure out, what exactly it does. do they detect the 0 as the start of teh sample, or the 1 as the full signal value when the groove has run throughout it;s whole length?

if you have time to explain this, i'd appreciate this very much, thank you,

jrp

They're both detecting the start of the ramp but this may not be exactly 0. change~ isnt looking for a specific value but is detecting when the signal changes direction - it outputs a -1 when the signal decreases. This is what triggers the slaved groove~. The delta~ is doing much the same, but it outputs tha actual difference in consecutive samples.

Hope i make sense. jan.

It's a sync outlet so things like establishing master and slave connections to sync start of playback and amp-envelopes can use this to sync at sample-rate. Just figured I'd also chime in and tell you to check out the example in the examples folder which is pretty essential learning for sample usage whether you use groove~ or anything else:

Max5(or 4.6)/examples/sequencing-looping/audio-rate-sequencing-looping/grooveduck.maxhelp

and grooveduck2.maxhelp in the same folder as well as the patches they depend on located within the "lib" subfolder.

Groove~'s interpolation doesn't smooth everything perfectly so you often need to sync an amp-window/envelope. The grooveduck examples are one of many innovative ways to do this and the other ways often run on similar principles(0-1 ramp for a clock signal).

thank you, jan.

i'd assume one could as well instead measure the time, when the signal slips back to 0 instead, not? this would give one a small timeframe in advance of the loop start to already send a trigger, instead of always beeing behind the actual master groove start, if just a tiny little bit.

how could this be done?

jan(ek) - jrp

thank you rabidraja, i'll make sure to check the grooveduck examples again!

)stupid me: grooveduck is what i am actually using...)

jrp

I'm not quite sure i Know what you mean. The second output of groove~ is already measuring the passage of time between the start and end loop points. So, I guess if you want to trigger another event slightly early you could use something like >~ 0.99 instead of checking for the start of the ramp.

But i don't think this is a good idea. The problem is that you have to trigger the slaved groove~ with a message rather than drive it with a signal - so it's unlikely to be sample accurate. Her is a link to another thread talking about sample accurate timing:

HTH jan.

Quote: jayrope wrote on Sun, 07 December 2008 14:06 ----------------------------------------------------

> i'd assume one could as well instead measure the time, when the signal slips back to 0 instead, not? this would give one a small timeframe in advance of the loop start to already send a trigger, instead of always beeing behind the actual master groove start, if just a tiny little bit. > > how could this be done? ----------------------------------------------------

jan, thanx very much for your expertise.

i am actually triggering the slaved groove~ with a message of course. i was just wondering if grabbing the highest value before loop start would supply any timing advantadge. actually, though, i don't need to be sooo timing exact, since i like the musical output of vague timing in general. meanwhile i am wondering if i can derive timed fragments from the example you demonstrated. looking at the curve of the output on a signal scope i wold assume, that grabbing >~ 0.25, >~ 0.5 & >~0.75 could give me quarter values as well. is that any useful idea, especially when trying to be exact in the first place (let alone the love for dealing with the vague). or would you go a different way to establish that, more exact, again?

appreciate your experience here very much already.

jrp

Well you could use a rate~ on the sync output and get 1/4 note (or anything else) that way.

Most of the time if i use groove, i'm triggering it from a metro and the timings usually good enough. If a more accurate timing is needed you could drive everything from a master phasor and use objects like play~ or wave instead. You might also find the el.player~ from the potpourri library helpful for real tight timing.

jan.

thanx for the hints, jan.

i was looking for a way to derive microtiming from the groove length itself, as i am using this in conjunction with live looping. so i want to be able to derive a midi clock or a timed off-sync for other loops playing eventually, or as a trigegr for a panning, etc.

here's a working example on the base of what you posted before. it's a bit crude, and especially touchy, when you change the geographical order of the parts on the right side, but it works. especially it allows for unsual divisions, like 5 or 7 or 9 or 11 or basically any number one dials in, as a base for rhythms. somethign i always wished to have in midi, but never got, as 4 is the dictator there.

not anymore, ha.

erm, i guess this can be improved. happy about any contribution to this.

jrp

free division groove sync patch.

____________________________________________< dist (clamped ibook)> 08/12/09 11:32:41 PM