Hello, to put you into context I'm working on a waveguide-style physical modeling synth in PlugData (basically the same as Pure Data), and I'm running into an issue where my delay line won't produce high-pitched notes correctly. I'm using a [delwrite~] and [vd~] or [delread4~] combo, with the delay time calculated from frequency using [expr~ 1000 / $v1], where $v1 is the pitch in Hz (converted from MIDI with [mtof]). The delay time is in milliseconds.

The patch works fine for low and mid frequencies, but when I try to play higher notes (especially MIDI note 100 and up), the pitch output seems stuck. it just keeps playing the same note, i doesn't happen with low notes though.

I've already tried the usual fixes. I made sure the [delwrite~] buffer is small (100 and even around 5–10 ms), verified that the delay time input is a smooth signal ([sig~]), and tried both [vd~] and [delread4~] for interpolation, nothing works.

Out of curiosity, I tested the patch at a global sample rate of 96,000 Hz. That actually allowed the waveguide to reach the correct higher notes, but the patch became very laggy and glitchy, and the CPU usage was noticeably worse (as expected)

At this point, I'm wondering if there's a clean way to make a delay line in Pure Data (or PlugData) that supports very short delay times for high pitches (e.g. MIDI 120+), without needing to oversample the entire patch or push the sample rate to 96kHz. Is there a known solution for sub-millisecond delay accuracy that works well in Pd? Would a local oversampling strategy using [block~] be effective here? Any guidance or best practices would be really appreciated

@Juicy-Jr Are you making sure that delwrite~ is executed before delread4~? If not, I'm guessing that at sample rate 44100 and block size 64 your frequency can't go above 689 (44100/64). If I'm right, take a look at Pd vanilla help 3.audio.examples/G05.execution.order.pd.

@jameslo thanks, ill give it a read and see what i can do, thanks for the info

@Juicy-Jr Caveat: if you have feedback, then that ordering technique won't be possible. In that case, I think your best option would be to reduce the block size, e.g. [block~ 1 1 1].

@jameslo y Jr
yeahh that's what i tried to do earlier, but it strikes the cpu up to 80% which isn't the best method, and also im building it to be polyphonic later so imagine the audio performance after polyphony, i guess its the most straightforward method to do it but if its about my computer then i guess i'll just have to stick with the problem lol, i'll still hear any suggestions

@Juicy-Jr Some additional thoughts:

• In case you thought otherwise, [block~ 1 1 1] does not oversample, it just makes the block size 1.
• You could apply the smaller block size to a subpatch or abstraction and isolate the feedback portion inside it. That way you only pay the CPU price for the stuff that needs it.
• MIDI 120 = ~8372 hz, and 44100/8372 = ~5, so [block~ 4 1 1] would suffice and be a bit cheaper. [block~ 8 1 1] would get you to MIDI 112.
• I know I'm in the minority, but I feel that my CPU works for me, not the other way around, so if something is computationally expensive, I don't worry about it until my machine can't keep up. Pd's load meter seems to exaggerate in Win10 because I routinely run at loads >100%. Finally, you can use [pd~] to distribute computation among several cores if necessary.

@jameslo that could actually work, i already made the subpatch with the content of the delay line, the problem would be to try and "isolate" the feedback, but ill see what i can do, thanks!