Sorry, I didn't know exactly how to word this in the subject.... but here goes:

I have a 64 step sequencer with 6 different "tracks" all running off the same metro. (when I say track, I'm referring to the 64 steps for one particular sample) I can change the number of steps for each track, so let's say I can have the track with the bass drum count up to 16 before looping, have the snare track count up to 20 before looping, have the hi-hat track count up to 9 before looping, and so on. They can all be set to the same number of steps or however you want, but they still all follow the same metro bangs. In other words, even if you set them to different odd lengths, they stay sounding in time with each other.

So my question is, can I make it so the overall length of time for each track stay the same and have them count through different amounts of steps? Like I could have the bass drum do a straight 8 count, and have the snare do a 13 count, but have them both begin and end at the same time. Like squeeze (or stretch) one or the other so that you would be offsetting them rhythmically, but the time it takes to count to 8 and the time it takes the other to count to 13 be the same length of time.... just a different number of steps.

Does that make any sense? Maybe not in a musical sense, but in a mathematical sense? I know it's not hard to create chaotic patterns with Pd (which I know would probably be the result of what I'm talking about) but I still want to try it.

You know, I'm glad you asked this, because I've been meaning to come up with a [phasor~] based clock to deal with something like this. See the attached patch; I'm sure you could modify it to suit your needs.

Edit: just realized that I didn't leave any comments explaining what's going on. I've replaced the attachment with one with comments.

http://www.pdpatchrepo.info/hurleur/phasorclock.mmb.pd

OK. I'm not gonna pretend like I fully understand everything you put together... but some of it looks familiar. However, I don't know if I'm missing something because when I hit play I don't see anything happening. I would assume the number boxes down at the very bottom should be counting up but they just stay on zero. I did just start messing with it though, so maybe it will give me an idea of where to start. Thanks.

Well that was weird. I swear it wasn't working a second ago, but now it seems to be counting up.

OK. So I closed it and opened it again, and apparently it started working after I right clicked on wrap~ and opened the help window. Otherwise it won't function until I do that..... what? I'll keep messing with it.

Does this need to be in bpm because of the phasor? It's kinda throwing me off since everything I've done has been in milliseconds with metros.

Very cool. I was still able to incorporate it into my sequencer. Maybe not the most musical method, but is still kinda cool. Thanks for your help once again.

The reason why it's not working until you open [wrap~]'s help window is because audio needs to be turned on. The help patch does this automatically with:

[loadbang]
|
[; pd dsp 1(

So I'll try to explain how this patch works. It's based on using a master [phasor~] object for everything to sync to. I used beats per minute because Hz is the same thing as cycles per second. By dividing bpm by 60, you get beats (cycles) per second. It's just easier math (to me) than using ms, and it's more musically intuitive anyway.

The signal for the [phasor~] is multiplied by the beat division, scaling its range. So if you want the beat divided into four subdivisions (16th notes), it will be scaled up from 0-1 to 0-4. [wrap~] takes a signal and wraps it around so that it falls within a range of 0-1, so 2.3 will become .3, etc. It essentially just gives you the fractional part of a number. Sending the scaled up [phasor~] output to this results in a ramp that is synced to the subdivision. This is then subtracted by .5 to scale the range from -.5 to .5, just so there are some zero-crossings.

[zerox~] is used to detect the zero-crossings. It doesn't seem to have a helpfile, and I'm not sure what the difference between the to outputs are. I just know they very briefly spit out a 1 when crossing zero. [edge~] detects sudden jumps in a signal and outputs a bang, which is used to drive the counter.

It's just occured to me that [zerox~] detects zero-crossings going up and down, and I designed the patch with the idea that it should only detect signals crossing downward. So it's actually going twice as fast as it should! Dividing the bpm by 120 instead of 60 should remedy that.

Hope that helps.

That must be what was confusing me. It seemed a bit fast, but I'll try it with 120 instead of 60. I'm sure that will clear everything up. Can't wait to go home tonight and mess with it some more.

Thanks for taking the time to explain how it works. It's pretty much exactly what I wanted. Respect.

This is a really awesome patch Maelstrom, thanks for building this. It will really come in handy.

Hi,

I've got a quick question to Maelstroms patch.

When I hit [stop( once while playing, then [play(, the counter are out of sync, meaning, they don't hit 0 at the same time anymore.

When I hit [stop( twice before hitting [play( again, the counter are in sync.

So, for now I fixed it for my needs with a [delay], sending the needed second hit.
But I would really like to understand what is going on.

Is it something I'm doing wrong or what?

Anyway, thanks for the awesome inspiration with the clock solution.

Regards,
j