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 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.

@nicnut said:
"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."

Maybe write the output of the [phasor~] that is driving the synth to another channel of [writesf~] as you write the audio file.
As all the tracks are audio there will be no jitter and the saw waveform will give you the visual aid to align with the click/midi/bar lines in the DAW.
The saw track can remain but be muted in the DAW in case you want to slip the track later.
David.

I usually control my patches by routing midi from my DAW to PD via JACK. Then at some point I will route the PD audio back to the DAW for a 'mix-down' of what the patch is doing... This way timing discrepancies between the two are minimal.

@whale-av Hey that's a really good idea to use Phasor~ as a visual aid. I will try that.

@ddw_music said:

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

no, many objects will only update after 64 samples, still.
(LATE EDIT: actually there are some control objects, wich are (sub-)sampleaccurate, such as [del] [pipe] [metro] [vline~], maybe some more. I am still confused about that whole topic. But surely the GUI and Midi/OSC ect i/o happen between blocks of 64 samples only. So take the following with a grain of salt.)

To change this, the blocksize of the root must be changed I think, and this is possible by changing some of PD's code and recompile, I think.
The Bela-board uses a modified libPD with 16 samples, instead of DEFDACBLKSIZE = 64

And there is the -schedlib <file> flag for loading a different scheduler on PD's startup, but I don't know how to do that and there is no documentation.

PD's scheduler doesn't make any difference between MIDI, GUI and control-objects.

The only way for really tight midi-out is Expert Sleepers hardware: The idea is to communicate via audio- the midi messages are encoded in audio and send sample-accurate to the hardware.

The same goes for syncing to a DAW ect.:
audio-click from the DAW, instead of Midi.

As soon, as you go into the control domain, things become sloppy, if you want to sync to the outside of PD with sample-accurancy or do feedbacks.
If you stay in PD only, you can try to keep tight timing by careful patching: using [vline~], writing and parsing buffers, and there are the iemlib T3 objects for this, too.
But this is not intuitive.

This is 'something I wish I knew when I started with PD' because all those simple sequencing examples with [metro] on floss-manuals and in other places, are sloppy.

I wish Midi could have a higher priority and higher rate, [block~ 1] would have more of an effect or we could call an interrupt or something similar...

EDIT: here is some discussion on github about it:
https://github.com/pure-data/pure-data/issues/1549

@nicnut

i dont know about pd, but in max you can not be sure that phasor~ really reaches a "true" 1.0 in float IEEE.

so you are better advised to track for the direction change in order to find the "1." within the same sample of the "1." - or actually the "0.", because "1." and "0." is the same moment in a phase accumulator.

in case there is no factory external you might need to use a delay~ 1 to track the direction change, which means that your system will have 1 sample latency.

but this is still better to use than treshold~ 0.5 - which will work, but brings new problems when used in a complex application.