A basic Math pipe would be extremely useful. Right now, I don’t even know how to divide a number, or get its modulo value. The pipe could either be something like the “expr” object in max/msp or even simpler (to avoid checking the expr syntax) have a drop down menu with a choice of operations and other ones for the operands.
1 Like
Transform Midi CC > Sysex < Midi CC
I had an idea where I think Variable Mapping could be useful: to prevent CC jumping. Granted, this is in a situation where the MIDI Controller and the device receiving the Midi CC value are not setup to prevent MIDI jumping. In this case I believe the equipment being controlled would not (Dirtywave m8), nor does the MIDI Controller (Denki-oto Hachi-Ni).
For example, say you’re using a Midi controller with Pots (not Encoders) and you have multiple pages. Say Page 1 is CC’s for Track Volumes of a device and Page 2 is something else entirely. If you were to increase CC’s on Page 1 (thus physically turning the knob from say, 0 to 127), then switch to Page 2 - set the knob to another physical position then return to Page 1 and adjust the Track Volume, it could jump from 127 to whatever the value now being sent would be.
If there was a way for the MidiHUB to store the most recently received value for Track Volume and then when it receives the next value, compare the incoming value to the stored Value to determine if it should allow the incoming data through. In the example above, the MidiHub would not send out the CC value for Track Volume until the knob physically met or exceeded the stored value, which was 127 (so it would have to meet the value).
This would allow less featured Midi Controllers and equipment lacking a kind of “check incoming value before applying” feature to avoid value jumping.
Hey Erik, the recently added CC Table has a Takeover Mode which is related to what you’re suggesting.
That, however, is for when multiple mapped controls to modify the same CC Value and I can’t see immediately how one could easily leverage that at present for one control.
Maybe in the next firmware improvement @Blokas could add a Continuous mode (with the caveat it would mess up “switching” messages!)
2 Likes
Ah, thanks. I’ll have to check out the CC Table block. I wonder how it would behave with a singular Control mapped to a Table Slot. My initial read is that it might do the trick - but I haven’t tested that in a working case.
My hunch is unfortunately not.
I have a sneaking suspicion that it will currently need a rather clunky work-around which would send a secondary mapping into CCTable a short time after “new” CCs stopped arriving.
This secondary mapping would just be the last new value , so that it was stored ready to listen for (& ignore) a new “jump” value from the original map.
It would need pipework on a per-CC basis and mechanisms to prevent feedback, etc.
That’s why I’m hoping the guys will see your request as a good Mode addition to CC Table!
I’d like to see this as well. I have a guitar set up in which I use an expression pedal. My workaround is to map into a cc table that’s set to immediate, then to a drop transform, into a virtual Port that loops back into the input value parameters of the drop transform that is set to outside range. The same loop back also goes to the bypass of the drop transform we’re its scaled down to 127 so the transform bypasses.
It works well. But it requires a separate transform for each parameter on my pedal board. So, it can become pipe intensive.
@Giedrius what are the possibilities of the continuous mode feature being added in the next update?