Something that might be obvious to some people here, but wasn't obvious to me --

If you're trying to sample an LFO signal and use this to control video, make sure that the sample rate is an exact multiple of the control block size. This is not the case for 44.1 kHz vs a 64-sample control block (but it is the case for 48 kHz vs 64 samples).

In this patch, it looked like the logic was correct, but the LFO "jumps" about once per second.

ofelia-timing-glitch.mp4

But if I start JACK with a 48 kHz sample rate, then the same patch is perfectly smooth.

Curiously, though, setting the block size to the largest power-of-two factor of 44.1 kHz ([block~ 4 1 1]) doesn't affect the behavior at all. (Fun fact: 44100 = 2*2 * 3*3 * 5*5 * 7*7.)

Probably this affects any similar use of [tabwrite~] but the impact is more dramatic when it's controlling graphics.

Something to be aware of...
hjh

@ddw_music I believe that if your LFO is within the blocked sub-patch...... and the sub-patch has no inlets or outlets..... you can set any block size you wish. The help file for [block~] states specifically that it is allowed for use in video processing.
David.

@whale-av

I believe that if your LFO is within the blocked sub-patch...... and the sub-patch has no inlets or outlets..... you can set any block size you wish.

Unfortunately, restructuring the patch as follows doesn't resolve the issue. (The sub-patch has control inlets, but they aren't time-sensitive. There aren't any inlet~ or outlet~ objects.)

So there is something else going on. My best guess would be that Ofelia's draw timing is quantized to the main patch's block size, and doesn't care about subpatch reblocking. (The "bang" feeding tabwrite~ is coming from the Ofelia backend, not from [metro] or any other Pd timer.)

hjh

until I know ofelia.perform() or M.perform() function can deal with dsp tick sync.