The choice really depends on how you want to work. With [phasor~] it's (generally) pretty easy to use one master [phasor~] and divide the signal into whatever subdivisions you may need. You can also do smoother tempo changes since the frequency can be updated at audio rate. But while you have a sample-accurate clock, converting it into messages/bangs loses that accuracy. [edge~] and [threshold~] are the only objects that I've used to convert a [phasor~] clock to bangs, and both conform to block boundaries and have a minimum limit of 64 samples. So if you need sample accuracy with [phasor~], then you have to find a way to keep your events triggered with audio signals, which is not very easy.

[metro] is really just easier, and for a drum machine it's probably the best way to go. Pd's [metro] is pretty damn accurate (it's the one in Max that is prone to drift). Most of the time you'll be triggering events at message rate, and so using [metro] with objects like [vline~] will actually be more accurate than [phasor~]. And for a drum machine, you might find that pretty important.

I'm hoping this 0-1 square wave conversion may solve the following similar issue:-

How to automatically stop a phasor one cycle after re-setting the phase.

I have tried using the samphold~ object combined with env~ or snapshot~, so that when the phasor wraps around, the samphold~ samples a 1 signal, which can then be used to set the phasor to zero (effectively stopping the phasor). See below:-

[r $0-phasestop]
|
[0(
|
[phasor~}
| \
| \
| [sig~ 1] \
| | \
| [samphold~]
| |
| [env~]
| |
| [sel 1]
| |
| [bng]
| |
|

However, it doesn't seem to work, perhaps it creates a feedback loop. Is there any way of telling the phasor to run for only 1 cycle at a time?

boonier: I didn't realize Pd's [metro] is that tight. I guess I just assumed I'd run into the same problems I did with Max.

Here's the setup I use for [phasor~] clocks:

[phasor~]
|
[*~ 2] <--used to divide beats, e.g. if [phasor~] cycles at a rate of one 4/4
| measure, 2 will give half-notes, 4 gives quarters, and so on
[wrap~]
|
[expr~ $v1<.5]
|
[edge~]
|
[bng]

What's also nice about this is all of your beat divisions can link up to one [phasor~]; and if you stop the [phasor~] inbetween beats, you can pick up exactly from that point without things getting out of sync, which you can't do with [metro]. I haven't done this yet, but you could also use one of the [wrap~]s to lookup, say, a drum loop in an array, so when you speed up or slow down, the loop will stay tightly in sync as well, albeit with pitch changes.

Ok: what it does is derive a second phasor from its input phasor.

If you want to go from [phasor~ 2] to [phasor~ 4], you can just use [*~ 2] and [wrap~]. If you want to go from [phasor~ 2] to [phasor~ 1] or [phasor~ 3], just using [*~] and [wrap~] won't do the job.

The patch I posted does some differentiation and integration, taking into account the jump in phasor~ and wrapping the output while integrating (to avoid float precision problems)

And now I realize that this is the solution to a different problem - will see what I can come up with for the real problem...

Hi, advanced users!!

I'm trying to make a little sequencer using metro, counter, mod and [sel] object.
It's a copy of obiwannabe tutorial 001.

But since I sequence 3 instruments at the same time with a single toggle object to
on/off metros, I need to all 3 metros starts at the same value each time I stop and restart metros.
one metro is attached to counter and it starts everytime where it was stopped previously....

other two metros, no idea where it starts each time!!

It's very hard to sync them humanly.
Is there a way to start a counter and metro everytime from 0??

here's the part of my patch

#N canvas 73 76 927 339 10;
#X obj 296 104 + 1;
#X obj 253 105 f 0;
#X obj 256 83 t b b;
#X obj 251 134 mod 16;
#X obj 241 161 select 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15;
#X floatatom 289 217 5 0 0 0 - - -;
#X floatatom 452 241 5 0 0 0 - - -;
#X floatatom 241 223 5 0 0 0 - - -;
#X floatatom 373 221 5 0 0 0 - - -;
#X floatatom 422 195 5 0 0 0 - - -;
#X floatatom 535 220 5 0 0 0 - - -;
#X obj 538 37 tgl 15 0 empty empty empty 0 -6 0 10 -262144 -1 -1 0
1;
#X obj 574 153 bng 15 250 50 0 empty empty empty 0 -6 0 8 -241291 -1
-1;
#X obj 816 121 bng 15 250 50 0 empty empty empty 0 -6 0 8 -241291 -1
-1;
#X obj 760 88 del 960;
#X obj 750 39 metro 960;
#X obj 274 12 metro 120;
#X obj 591 115 del 120;
#X obj 550 83 metro 1920;
#X floatatom 345 127 5 0 0 0 - - -;
#X connect 0 0 1 1;
#X connect 1 0 0 0;
#X connect 1 0 3 0;
#X connect 2 0 1 0;
#X connect 3 0 4 0;
#X connect 3 0 19 0;
#X connect 4 0 7 0;
#X connect 4 1 5 0;
#X connect 4 3 8 0;
#X connect 4 6 5 0;
#X connect 4 9 8 0;
#X connect 4 11 9 0;
#X connect 4 15 6 0;
#X connect 4 16 10 0;
#X connect 11 0 15 0;
#X connect 11 0 16 0;
#X connect 11 0 18 0;
#X connect 14 0 13 0;
#X connect 15 0 14 0;
#X connect 16 0 2 0;
#X connect 18 0 12 0;

thanks in advance!!!

I'm not sure that the annoying scratchy sound is caused as you say. More likely it's aliasing that you will get whenever you frequency modulate a phasor. The best way around this is to use a band limited sawtooth instead of a phasor.

Any instantaneous change in frequency will be heard abruptly, so you really want the smoothest change possible throughout the duration of each cycle. You could control the phasor frequency with a smoothed audio rate signal [sig~]-[lop~ 3]-[phasor~].

To answer the last question. Make your own phasor with [vline~] and [metro]. The slope remains constant between bangs.

read this thread about how Pd deals with logical time and dsp:

http://lists.puredata.info/pipermail/pd-list/2007-05/049788.html

also, if you have an example patch, it would help - i'm not sure what you mean by "driving a table".

if you're worried about metro only updating its period at the next bang, you could use a frequency number to vline~ (for subblock accuracy, if your frequency is a signal already don't bother with this) to phasor~ combo instead of a metro and vline~ - the problems here are setting the phase of a phasor~ isn't subblock accurate, moreover getting a bang from the falling edge of a phasor~ isn't subblock accurate either, and you wouldn't be able to sync a metro to it accurately because of the first sentence in this paragraph....

one solution is to do everything with signals, with things like samphold~, but that can be cpu expensive....

Short version: Is there a phasor~ analog which functions in the control realm of pd?

Long version: I've been messing around with using Signals to play samples with Tabread4~ and the modulationg them etc. The basis of most of these "loops" is a single phasor~. It would be great if there were a control rate phasor that would allow me to sync two tables, one for audio data and one for performance/control data. I've been using Counter from the GEM and a metro but this does not seem like the most elegant approach as it has dependency and is harder to sync with the phase of the phasor~.

Any suggestions?
--Nestor

_for example: I want that a bang message is sent whenever a [phasor] obj
is at 0 . _

I don't know whether there is an object that does that, but you could make an abstraction to do it.

You can use [expr~] with relational operators ( > , < , = , etc ), and I think Zexy has an object [avg~] which outputs the average of each signal block (signals are processed in blocks of (usually) 64 samples).

One thing you have to be aware of is that there may not be a time when the phasor~ is exactly zero, because the period of the waveform might not be an exact number of samples.

Something like this might work, though:

[phasor~]
|
[expr~ &#036;v1 < 0.05] <-- change 0.05 by trial and error so you get one bang per cycle of the phasor~ (try [expr~ &#036;v1 < &#036;f2] )
|
[avg~]
|
[> 0]
|
[select 1]
|
outputs a bang at (very slightly after) the start of the [phasor~]'s cycle