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] [metro] [tabwrite~] [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...