Spent a couple of days learning PD...I went to use it today...not just switching but actually playing midi through it...the latency is definitely unplayable.

I tried just a straight in/out connect and the latency is still there despite and coding.

Here is the patch

B_A_Sustain 05.pd

Have I done some huge mistake?...specifically Im just talking about the pass thru of midi via the MidiGuitarFilter sub patch. Im using UR44 for live i/o and it plays fine when I correct directly from midi keys (about 5ms but is reasonable) to a softsynth.

SOLVED: Go to Audio Settings and turn off ins and outs (where you are just using PD for midi handling). Even though you may not be using the audio in PD, it still uses the latency settings of the audio.

@image_engine Hello again.
Your audio settings must be incorrect for your computer audio setup.
Many people are using midi and audio in Pd without problems, and what you are seeing is Pd struggling to execute its audio stack...... and as Pd gives audio priority (makes sense) every other operation including midi is delayed (what you experienced) or cancelled (Pd hang).
Obviously your solution works for you now which is good.
David.

Yes...it was strange...as soon as I unticked the inputs/outputs...away it went.

I run all my midi-only (or other serial control) patches in their own instance of Pd that I start from a separate desktop launcher that starts Pd with these flags:

-noaudio -audiobuf 1 -alsamidi -sleepgrain 0.5

I've tacked on the -rt flag too but that probably doesn't make much difference for a control rate patch. In fact the combination of the above flags is probably overkill, but I figured I'd keep all options covered. On a multi-processor machine you may also be able to use the -nosleep flag if you really want max throughput and don't mind running one proc full-time, but perhaps someone with more experience would like to comment on that...

Nice tip...cheers

BTW -alsamidi is linux only. Not sure about any additional flags on the other systems.