synchronization using phasor~

Aug 23, 2010 at 8:33pm

synchronization using phasor~

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 bars.beats.units @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!

#51950
Aug 23, 2010 at 8:41pm

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.

Cheers.

#186410
Aug 23, 2010 at 8:45pm

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?

#186411
Aug 24, 2010 at 4:29am

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.

– Pasted Max Patch, click to expand. –
#186412
Aug 24, 2010 at 11:31am

Sorry, should have been:

– Pasted Max Patch, click to expand. –
#186413
Aug 24, 2010 at 7:07pm

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.

cheers!

#186414
Aug 24, 2010 at 7:08pm

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.

#186415
Aug 24, 2010 at 8:51pm

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.

#186416
Aug 24, 2010 at 8:58pm

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.

-A

#186417
Aug 24, 2010 at 9:17pm

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.

#186418

You must be logged in to reply to this topic.