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