PD 0.49 stops responding to MIDI if I send it a lot of messages, e.g. the output of a Korg nanoKONTROL2 when I move all 8 faders at once, and it doesn't respond again until I restart PD. It happens even when the Test Audio and MIDI window is the only thing open. It happens on Windows 7, Windows 10, and macOS 10.13. MIDI-OX shows that the Korg controller is fine.

I temporarily reinstalled PD 0.48.1 on Windows 10 to test, and it happens in that version too. I noticed I had left a version of pd-extended (0.43) on that same machine, so I tested it as well--it was fine! So I guess that's the version I have to run with for now. Anyone else having similar issues?

I have the same issue, with a nanokontrol 2, pd vanilla on osx. I don't know how to solve this. Have you ever noticed this with another midi device?

@jameslo Maybe a solution from @Berenger....... https://forum.pdpatchrepo.info/topic/3651/midi-input-cpu-overload
A quick Google says that Pd is far from being the only midi receiver that has problems with the Nanokontrol.
David.

It never occurred to me to suspect the nanoKONTROL, so thanks for that LucienR and whale-av. I configured my Yamaha 01V96i to output MIDI to PD 0.49 (yes, vanilla) and everything worked fine, which is remarkable because it generates twice as much fader data as the nanoKONTROL. But I think I'd still rather run my patch on pd-extended 0.43.4 than lug this mixer to my show, unless someone tells me that's a bad idea.

I tried that tip from Berenger (i.e. using a separate ctlin object for each controller) but PD 0.49 still hung. In fact, I can run PD 0.49 with nothing but the parent window open, wiggle the nanoKONTROL faders vigorously, then open the Test Audio and MIDI window to see that PD is no longer responding to MIDI.

@jameslo Did you try putting separate [ctrlin] objects for each midi fader into a sub-patch and using send and receive objects to the main patch (not opening the sub-patch or the "Test window".......ever....!)?
It would be interesting for others if that is a solution.
And I wonder if the NanoKontrol2 still sends to the non-existant midi ch 0 from the first fader, as the older one did? Could that mess up the messaging?
David.

@whale-av Yes, I tried two different ways using a combination of subpatches and abstractions, neither worked. So that's why I tried testing PD with nothing but the parent window open--no patch at all!--and PD still stops responding to MIDI after I move several faders at once quickly.

I looked at the first fader using MIDI-OX and it is sending on channel 1 as configured.

@jameslo Oh well. Another win for "extended" then.....
Thank you for doing the testing.
David.

That's quite a shame. Makes me nervous... though I must say, I haven't experienced it (yet). I just tried both Nanokontrol and Nanoknontrol2 on my AVLinux (Debian) system with PD 0.49.0, and nothing untoward happened. Jigglin' those li'l sliders fast as my fingers could allow, all 8 at a time sometimes.
This is just with the "Test Audio and MIDI" patch open, right?

@Load074 On my systems, I don't even need that "Test Audio and MIDI" patch open to make it fail, and it doesn't take much fader wiggling either. But if you can't make your system fail, then that's good news for you, no?

@jameslo have you ever noticed this with any other device? I've decided to drop the nanokontrol and look for something similar, but i wonder if i might encounter the same issue, or if it's really related to the nanokontrol.

@LucienR No, but the only other device I've tried is the Yamaha 01V96i.