4.63 - what is groove's 2nd outlet good for?

    Dec 06 2008 | 5:32 pm
    hello again, this question probably seems stupid to you experienced max users again, please forgive my newbieness.
    what do people use groove's second outlet for?
    i could imagine to use it to sync other groove objects to one master object, but this seems hindered by the absence (correct me i am wrong, please!) of an object able to read the loop positional signal from the second outlet to data, without a 20ms limit on the frequency of reading values.
    is there an object for finer or even sample accurate resolution, nevertheless? and what do you groovers use the second outlet for as well?
    thank you very much for any more insight.

    • Dec 06 2008 | 7:10 pm
      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.
    • Dec 06 2008 | 7:37 pm
      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.)
    • Dec 06 2008 | 9:33 pm
      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,
    • Dec 06 2008 | 10:20 pm
      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.
    • Dec 06 2008 | 10:22 pm
      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).
    • Dec 07 2008 | 9:06 pm
      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
    • Dec 07 2008 | 9:07 pm
      thank you rabidraja, i'll make sure to check the grooveduck examples again!
      )stupid me: grooveduck is what i am actually using...)
    • Dec 08 2008 | 5:40 pm
      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? ----------------------------------------------------
    • Dec 09 2008 | 2:54 am
      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.
    • Dec 09 2008 | 10:15 pm
      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.
    • Dec 09 2008 | 10:33 pm
      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.
      free division groove sync patch.
      ____________________________________________< dist (clamped ibook)> 08/12/09 11:32:41 PM
    • Dec 10 2008 | 9:31 am