@oid Thanks for that! I will try to implement something to increase the step size when turning the encoder faster, as well.

@oid I would be interested in your relative CC abstractions if you want to share them.

I have a midi twister fighter that I haven't properly set up yet, their configuration app isn't available for Linux but I have made some investigations and have figured out most of the sysex messages, although my patches are still in a rudimentary stage I should be able to do most everything except updating firmware through puredata. It's not a bad controller, but the support is a bit lacking/frustrating. The firmware is open source but I'm not there yet. Anyway if anyone is using one and wants to see the bare bones sysex patches let me know.

I also have a Linnstrument which is expensive but worth it, I reckon. Very open and well supported/documented. I'm working on a kind of framework at the moment, for using it with pd via their 'user firmware mode'. Should be a pretty good combo! Once that's up & running might dig into the firmware proper. Wish more hardware makers supported this kind of open source approach...

midi-up.pd

This is an updated patch, I hadn't quite got the hang of 'running status'. The patch now also has all the midi real time messages. The most helpful tutorial I have found for understanding how to handle midi is this one: https://learn.sparkfun.com/tutorials/midi-tutorial/all

(edit: updated patch in following message)

Hello, I have been fiddling around wondering about how to make a vanilla midiparser that can handle MPE messages like release velocity - your patch was really helpful, thanks!

I've completed it with all the types of 'midi status bytes' that I know of, and changed the routing system a little bit. It seems to be working well for me.

Thanks for the info about latency and the native notein object.

Hope someone finds this useful,
Sam.