Here is a suggestion for greatly improving mapping (which I believe is the only weak spot of an otherwise outstanding tool - which I am loving!).
Currently, mapping has no pre-processing, so you are very limited in the choice of controllers and actions you can effectively use for mapping, unless you “waste” an input and output for a MIDI loop (as synthdad does in some video of theirs).
This could be improved in an elegant and consistent way by just adding a “MAP input” and a “MAP output” pipe. They would work exactly as any oher input / output pipe, the only difference being they would pre-process map triggers instead of real or virtual IO ports. That would allow even “dumb” MIDI controllers to manage midihub complex patches.
If this proposal is too nerdy, sorry for that, I am a developer
I was thinking of ‘map input’ as a special input where only already mapped triggers where present, but in hindsight that would defeat most purpose of map pipelines, because you could only change the values of the messages (eg change a CC value or ‘note on’ velocity) but not the message type itself (eg remap a cc, a note message, channel, etc)
What’s really needed is just map output. It’s more straightforward and more effective.
Btw that would be awesome! Two use cases:
Currently, I am using a controller which I find excellent (Studiologic Mixface, no involvement with them) but it’s a little too dumb in some areas: it can’t do inverted switches like Beatstep (whch as a controller is inferior in any other area). So I am adding a filter pipe with mapped bypass to each pipeline, which works as a NOT operator. Being able to do the NOT operation just once in a map pipeline would be great.
I am using a fader for remapping channels (so that I can use my Blofeld keyboard as a master - changing channels on that is cumbersome). Since Mixface has an LCD which shows the transmitted value, at first I configured the fader to only send 1 to 16 (so that I could read the channel on its screen). But mapping a channel on midihub expects 0-127 and divides that by 8; I then had to revert back the fader to 0-127, but now I have lost the ability to read the correct channel on its screen. A map pipeline would let me send 1-16 values (and read those on the screen) and translate that into 0-127 for midihub channel mapping. Hope the way I explained it makes sense.
If this is going to happen I’m going to buy a second midihub just for the fun of programming it
Midihub is absolutely amazing and and in a league of its own. It really has “glued” my MIDI devices like nothing else before. I currently use one set of ports to enable my Blofeld (wonderful keybed, poor MIDI) to act like a proper master keyboard with the help of Mixface, a second set of ports for fixing my Roland MC101’s multichannel MIDI (great sounds, awkward MIDI implementation), and a third set as a replacement for a MIDI effect unit (Squarp Hermod: Midihub does more and better).
This was great to read
I’ve been using a beatstep as a controller and whilst the pads can be great bypass/ no bypass switches and other parameters are good matches for a typical 0 to 127 CC message from a control knob, many aren’t. As an example, I built a looper pipe with a clock divider in it, with the idea of being able to select the degree of division live. Simply, there’s just too high a range of control to be useful. In the clock diver case it went from something like div by 2 to div by 64 with the slightest touch of the control … basically unusable
Being able to pre-process midi before the are mapped to control pipe parameters will be wonderful … thanks
Phil.
Such a map pipe would open the gates of Midihub mapping heaven!