synchronization using phasor~

    Aug 23 2010 | 8:33 pm
    i'm trying to make a simple sequencer that controls other objects by cycling through beat divisions 1-16. i always want division to correspond to beat 1 of whatever bar is playing in live so that the rhythm plays consistently wherever i hit play. here's what i'm doing:
    [phasor~ @frequency 1 0 0 @lock 1]
    into [chucker~] with the signal value going to [change 0] so that only the integers are displayed, but the resulting timing is really inconsistent. it feels sloppy and swung. not sure why.
    any insight or alternative solutions are appreciated!

    • Aug 23 2010 | 8:41 pm
      insight: don't do it!
      lol, just kidding.
      I rewrote the timing engine for my plugins using a phasor several months ago because I realized it would be easier to implement swing this way. Everything was written correctly, but the timing accuracy of using a phasor just didn't cut it. Maybe YMMV, but I'd stick to using the transport object.
      There's a lot of ways to do things, but the short version is:
      Create a metronome quantized to the beat value.
      Send its output to a the input of a transport object.
    • Aug 23 2010 | 8:45 pm
      thanks - actually good to know that phasor isn't the way to go so i can at least stop messing with it. but how to i make it so that division 1 always corresponds to a downbeat from live's transport?
    • Aug 24 2010 | 4:29 am
      Tricky...I do different things in different patches, to be honest. But generally, you use the raw ticks output to start your sequencer (I use a counter), and use the beats output to select beat 1 and send it to restart the counter. I do that client-side, but here is the timing abstract that I wrote and use in all my patches. It's not as complicated as all that, but my abstract incorporates swing, which makes things a lot more complex. Get back to me if it doesn't make sense, I'll try and explain better.
    • Aug 24 2010 | 11:31 am
      Sorry, should have been:
    • Aug 24 2010 | 7:07 pm
      thanks, amounra - this looks great. i'll spend a little time with it before i bother you with questions.
      before you replied i was able to come up with a (less elegant) solution using some of the methods you described (restarting the counter, etc...) - although using the patch to start the sequencer seems like the key, otherwise the sequencer has to play until it reaches beat 1 of the next bar for the patch to sync up.
    • Aug 24 2010 | 7:08 pm
      Basically you can derive all timings just from the transport raw ticks output. For example, a quarter note corresponds to 480 ticks, i.e. dividing the output by 480 and applying modulo 4 gives you a beat counter 0,1,2,3 per bar. Or if you want 8th notes, divide by 240 and apply modulo 8 which produces 0,1,2,3,4,5,6,7 per bar. With this scheme it's also quite easy to implement swing just by adding some ticks of delay at the odd numbered positions.
      Note that all counting is derived from the global tick counter, i.e. no other counter objects are needed.
      Two things: (1) The metro must run with an interval less or equal your smallest divider, and (2) after division must be a change object to ensure that each number is delivered only once.
    • Aug 24 2010 | 8:51 pm
      Not wishing to hijack the thread but are there some timing issues with phasor~?
      Is phasor~ @lock 1 not tightly synced to Live's transport?
      Please explain.
    • Aug 24 2010 | 8:58 pm
      As far as I'm aware there are no timing problems with phasor~ @lock 1.
      Usually inaccuracies with this kind of thing come from the "sampling rate" of objects like snapshot~ and number~.
      If people believe they can see timing inaccuracies with phasor~,please post patches.
    • Aug 24 2010 | 9:17 pm
      I didn't know about the @lock 1 attribute when I was working with phasor....chances are it would would also have solved my issues, if that's others experiences. Without it, though, my patches were unusable from a timing standpoint.