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.

@fina said:

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

This can be a pain, faders (unless they are motorized) will jump, if you are at midi value 10 and switch too a different mapping that has that fader at max, when you move it it will jump down to 10, quite annoying but can be exploited and was a common trick on the early synths with patch memory that used analog controls, but this was generally more a hindrance than a help. Most modern controllers use endless rotary encoders which will update their values, in absolute mode you map out the controls on the controller itself and make presets, switch the mapping and the new values are there so no jump when you turn the knob but this has the disadvantage that they generally are limited to the low resolution 0-127 midi values. In relative mode the encoder sends only a plus or minus value so you can have unlimited resolution but you need to do more in pd since you need to add or subtract those plus or minus values from a stored value.

Personally I find mapping controls on a controller to be slow and I do need greater resolution so I do it all the mapping and the like in pd with relative mode, I made some abstractions to take care of all the work and they do some useful things like the first tick is ignored and just highlights the parameter being edited so when you forget what knob does what you can find your way without altering anything that is going on. This also means you are not limited by the controllers memory for mappings, I just do that in the patch so I have a virtually unlimited number of mappings. I use an Arturia Beatstep as a controller, 16 pads and 16 encoders, so each pad selects a mapping giving me 256 parameters I can edit or if I somehow needed more I could arrange the pads as 8 banks of 8 and 1024, but I have yet to need to do that. It also has the sequencer mode which is very limited but handy as an easy way to easily test sounds out. I can upload these abstractions if you decide on going with relative encoders, been on my list to get those uploaded but I tend to drag my feet on documentation so they have yet to get a proper upload, they have been uploaded a few times in various threads just not everything with actual documentation.

One thing to keep in mind, some controllers have software editors to make it easier to map stuff out, these software editors often do not work in linux even in Wine, so if you use linux you will want to make sure that the sysex commands have been published either by the maker or by someone who has sat down and figured them all out. For what ever reason some companies just will not release the sysex (Arturia being one of them). It is not terribly difficult to figure out the sysex on your own, just time consuming.

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.