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.
-
Audio rate Metro or counter?
-
@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 = 64And 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 -
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.