@jamcultur You need to adjust the audio buffer, for example using 512 (this will add latency in the signal, but maybe you don't care if you don't use [adc~] -> [dac~].

@flextUSer Neat! I see that you are using netreceive so it is really a standalone app? You could use OSC and make it a bit more compatible with other applications IMHO.

Also I am sure you are aware, but share for people searching for sequencer, trigger, timeline etc https://www.iannix.org/en/whatisiannix/

Do you have screenshot or demo of your external - patches in action?

I find [Black MIDI / Art MIDI] videos quite interesting:

I don’t have much time to dive deeper, but I took a moment to create a Pure Data (Pd) patch that sends MPE MIDI to a VST that supports it (Strike, Glide, Slide, Press, Lift – sometimes called 5D). It’s not exactly a Black MIDI MPE setup, but I’d love to see someone create a patch that truly showcases this concept...

⚠️ Warning: Contains flashing lights:

Patch (only using 1 note on channel 2)

mpe.pd

Crazy stuff. Keep up posting those please.

Another alternative is to use patreon, a good example:
https://www.patreon.com/ArtiomConstantinov

@porres Let's go! Looking forward to test this! Thank you sir.

Well, silly me, we have the Audio I/O Error shown in the main interface! I think this is a good indicator that PD wasn't able to process the DSP fast enough. Sadly I don't think we can log that or get the information in a patch to count the number of occurence...

Checking the source, I see this commented code, would love to have this information in the patch, or at the very minimum in the console log:

if (sys_getrealtime() > nt_nextreporttime)
    {
        post("%d audio I/O error%s", nt_errorcount,
            (nt_errorcount > 1 ? "s" : ""));
        if (nt_resynccount) post("DAC/ADC sync error");
        nt_errorcount = nt_resynccount = 0;
        nt_nextreporttime = sys_getrealtime() - 5;
    }

Thank you, I am new to Windows, trying to fine-tune the OS as much as possible to get super low latency (under 5ms). In linux when using qJackctl, on the main window, there's an "XRuns" counter that increments each time a dropout occurs.

The number in parentheses shows the number of overrun xruns. Overruns occur when the audio buffer is not consumed quickly enough by the system, leading to a buffer overflow.

The number outside the parentheses shows the total number of underrun xruns. Underruns happen when the system fails to provide data to the buffer in time, causing a buffer underflow.

This is what I am looking for to have in Windows or directly in PD.