Hey there! I'm trying to find a good and versatile midi controller for pd in general, to get more tactile and hands-on controls for different patches. While researching I stumbled upon lots of different controllers in different price ranges, starting with fader/pot controllers like the korg nanokontrol or novation launchcontrol (xl), midi keyboards like the arturia keylab/minilab and akai mpk (mini), or endless encoders like behringer x-touch (mini), faderfox uc4/ec4, or the intech grid controllers.
I'm always struggling with decisions and therefore thought about asking for your experiences. I'm especially worried about multi mapping the controls to different pages/layers and how the controllers behave if the pot/encoder is in a different position. so if you'd like to talk a bit about your experiences with midi controllers, what works best for you, what you think is important to consider, and how you implement midi controllers in your patches and/or performances, I'd be very thankful!
Kind regards, f.

Hope no one minds that I'm just jumping on to this month-old conversation... but I have some similar questions.

I was going to ask if anyone has ideas for better-than-128 resolution controllers (ie, not MIDI. HID? MIDI 2.0?). But looking at what @oid said, maybe my best bet is to settle on rotary encoders (giving up on sliders) and use "relative" mode to do the math in PD.

Is that the general consensus? All my ancient nanoKontrols are getting futzy anyway, it's time to upgrade...

@Load074 A controller with relative mode is the most versatile since you get a knob of what ever resolution you need without the issues of scaling, the trade off is that it is not as easy and does not just work right out of the box with most everything. No hardware that I have ever seen can read relative mode encoders, software seems to be a bit better but not great, so you end up always having to pd in the chain. If you don't use much else other than pd than this is not big deal, but it could probably become an issue with larger setups.

A sliders resolution is ultimately a function of its length, you can not just increase the resolution of a short slider since it would require the user to move it in smaller increments than is possible. If you want greater resolution you will probably will not have many options other than giving up sliders.

@Load074 How about 2 faders...... course and fine.....
Although mixing consoles control a large dynamic range with a fader, and usually send NRPN midi (14bit) ..... 16384 instead of 128..... which is part of the Midi1 spec I think... it is very old.
Yes, 16384 is 128 squared.
NRPN effectively sends course and fine in one midi message.
Controller 99 (MSB) and Controller 98 (LSB)
David.

Thanks @oid and @whale-av. I had actually made a similar (but uglier) version of NRPN before I knew about NRPN; some weird powers-of-10 stuff that didn't exactly make for smooth transitions... but it is something to think about. What I'd really like, though, is something where I simply have better than 128 points of distinction on a single controller... especially if I'm, say, scrubbing through a sample - if it's very long at all, it becomes obvious that I can't get halfway between two points. A two-controller method works, but isn't as faux-analog'ly satisfying as being able to nuance a single pot (like I love to do with my guitar pedals).
So I'll probably stick with relative mode and PD-side math (which I've also done before). I was just dreaming that there was some good, potentially non-MIDI hardware interface/protocol that I didn't know about!

@Load074 said:

non-MIDI hardware interface/protocol

That would be the various low level interfaces and directly communicating with the encoders themselves. It has advantages but it is far more work and considerably more expensive, making something like the $100 Beatstep that I use would cost $200 or $300 when all is said and done. This weekend I can polish up and upload my abstractions for handling relative CCs if you want.

@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...

@unclewayback Sure, you can find them here. https://forum.pdpatchrepo.info/topic/13385/midi-rotary-encoders-values-get-confused/2

Never got around to polishing them off and I would probably do things differently if I were to do it now but it does the job and I have yet to find the need to improve them.

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

@unclewayback It already has that, the velocity arguments sets that.