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.

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