Hi. This seems pretty basic, but I haven't been able to find anything. Is there a way to use a phasor~ to drive a metro or counter? Ultimately I want to create a sequencer from this. So, for example, a [phasor~ 1] would be 1 hertz, doing one cycle per second, so that would be equal to a metro at 1000 milliseconds. There must be a way to do this, but I'm having a hard time figuring this out. Thank you for any help or suggestiosns.

@nicnut [impulse~] from the sigpack or else libraries is a simple solution.
[phasor~] into [expr~ $v1 >= 0.9999] but it should be no more accurate than [metro] because [phasor~] probably never reaches 1.0000000000 at a block end and so an == test fails. Maybe == could work with [block~ 1]?
I am sure someone into fft will give you a much better solution though.
David.

@nicnut You can use [threshold~] to get a bang when ever [phasor~] hits a certain level.

@nicnut you can do something like this:

Edit: of course, if you need to translate from signal to control rate, threshold~ is the solution.
Edit: better use -~:

@whale-av said:

[impulse~] from the sigpack or else libraries is a simple solution.

I'm now catching the bug of "how can we hack that up in vanilla?" Phasor --> one-zero highpass --> (clip off small positive increments edit: not needed because clip~ later will do it) --> scale and clip to guarantee 1.0. ([*~] --> [clip~] is a workaround for the bizarre lack of signal rate comparators in vanilla, but eh, whaddayagonnado?)

(Would still need [threshold~] to flip this into control messages.)

hjh

Thank you for all the great replies. I don't see how I can get a bang out of threshold~ however.

I must be missing something here.

threshold.pd

@nicnut If you're trying to use audio signals I would wonder what you're driving with it.. perhaps consider the signal-sequencing objects from the lyonpotpourri library and keep the sequencing in the signal domain instead of converting back and forth.
however lyonpotpourri also has useful objects for translating between its signal-rate triggers and bangs and floats.

@nicnut [phasor~] only goes from 0 to 1 (at most, usually from a little over 0 to a little less than 1) so your signal will never trigger the upper threshold of 1. If it were me, I would trigger on the downward slope rather than the upward slope since it's more reliable and easier to detect. Try [threshold~ 0.6 0 0.5 0] and take the bang from the right outlet.

@jameslo yes that works! Thank you.

@nicnut I was just amending my post to say that there's nothing inherently wrong with putting a threshold trigger at, say, 0.5 on the rising slope, it's just that I often see people putting it as close to 1 as they can so as to trigger just before the phasor resets, and that seems unreliable to me.

@jameslo Yes. I don't know why, but I was trying to get it triggered at 1 also. It just seems that as soon as it hits 1 it will go back down so that seems safe. I didn't want to pick .5 because then it would get it on the up and down side of the wave form.

The way you have it, with threshold~ .6 0 .5 0 is it only sending out a bang once per wave cycle? It seems like as the wave form is going from 0 to 1 it would trigger, and from 1 to zero.

@nicnut [threshold~] has two outlets, trigger and reset, the first bangs when it exceeds the value, the second when it drops below, they are separated. Open the help file for [threshold~] and play with that number box, it will become apparent quickly.

@jameslo said:

If it were me, I would trigger on the downward slope rather than the upward slope since it's more reliable and easier to detect.

[phasor~] --> [rzero~ 1] --> [threshold~] will operate on the slope (delta-y per sample), so you could set the threshold parameters to fire on a relatively large negative spike, say, below -0.5. Or multiply the rzero by -1 and look for > 0.5 ish.

hjh

@old Ok very cool. Yes I can see that now, I am getting bangs out of both sides.

Actually I was looking at the threshold~ help file and it didn't really help me get anything figured out. It is sending out a print message and in the console nothing is being printed. I couldn't get any bangs out of it also. And I had the auido on. I really couldn;t figure it out, but I think now I have a better idea.

@nicnut Is there any advantage using [phasor~] instead of [metro] if you are returning to a control rate bang after the audio rate trigger?
Is there any advantage using an audio rate trigger when it will only "bang" at a block end anyway?
Is there any advantage using [threshold~] to trigger on a slope.... when the trigger will be late on the [phasor~] cycle?

If you are looking for accuracy I think you will need to use [vline~] instead of [phasor~] and stay in the audio domain. I am pretty sure that [vline~] will always go to zero and one.... and values will definitely be produced with sub-sample sample accuracy.
You would need to use [metro]....... or some other control rate trigger from your patch...... to bang in the messages to [vline~]
David.
This should be in your doc folder........
C04.control.to.signal.pd

@whale-av Ok thanks for that. For my purposes I want a waveform, It could be phasor~, impulse~ or something else. I'm making some binaural beats, isochronic tones, and tempo controlled LFOs. Everything is related to certain frequencies. It just makes sense to me that it all comes from oscillators and not metronomes. But this is good to know about vline~. I have noticed small wavering of tempo in other things I've done with Pd so I'll try using vline~ more in the future.

@nicnut Keep in mind that a small wavering in tempo can just be another layer to the beating, the rhythm itself can beat. I personally enjoy this limitation of pd and find it can be exploited to remove some of the mechanical nature of sequencing in a way more natural than adding simple swing or the tedium of note by note adjustment. But it can also be downright infuriating when you need that concise timing, especially when controlling external synths through midi. Generally this works best on slower things, when the tempo picks up the timing error becomes more distracting than anything, starts to sound sloppy.

@oid Yes I totally agree. I love the interesting hemiolas you can get with those slight waverings. I'm cool with that. However one thing that can be annoying for me is when i export Pd created audio files into a DAW and try and line them up with bar lines or a click. usually it can be time consuming as I have to adjust a lot of parts.

@nicnut Sequencing somethings from pd and some from another source tends to turn into a headache in my experience and timing gets sloppy in a bad way, This might be my own limitations or pd's, never bothered to look too deeply into it since it is easy enough to work around. This is a common issue in general, the more sources you have a timed data the more off things tend to get.

@nicnut said:

@oid However one thing that can be annoying for me is when i export Pd created audio files into a DAW and try and line them up with bar lines or a click. usually it can be time consuming as I have to adjust a lot of parts.

One under-appreciated fact is that most audio interfaces run slightly off of the true sample rate. SuperCollider can report Server.default.actualSampleRate and I find it's usually below the advertised rate, e.g. 44097.xyz rather than precisely 44100. Timing based on real time interaction will always be slightly off, in recorded files (such that I wrote a short SC script to resample by a fraction of a percent, when I need to sync a long recorded audio file with a screencast video -- after 15 minutes or so, the broken sync is already perceptible).

I'm not sure if Pd's control layer timing follows the sample clock or not. If it does, then in theory it should be consistent...? But I'm not certain.

For Pd's control layer to be sample-accurate requires a block~ size of 1, right?

hjh

@ddw_music Yes that makes sense. However a lot of other environments, in my experience don't have this fluctuation. When I record files from Max it seems pretty much locked to the tempo.
And moving files between Ableton and Logic is fine, the tempo is solid.
It could also be my hardware recording device, but it works with Max pretty well.

This is not a huge complaint on my part, as I really love working in Pd, but it would be nice to figure out this timing issue.