mf twister : different CC # on shift hold / shift toggle
I understand that the shift encoder hold and shift encoder toggle send out the same CC# on a different channel.
In my case the shifted value is sent on channel 1 ( manual says ch5 ).
Is it possible to send out different CC#'s on the same channel, instead?
I’m trying to control an app which can listen on one specific channel ( in which case it wont pick up the shifted values ) or on omni ( sees both knobs as same since it is the same cc# )
We’ll release an updated version of the MF Utility in the next few days that allows you to customize which channel is used for the shifted encoders among a bunch of other fixes but it will still share the same CC# as the encoder. Once it goes public you’ll see a notification when you open the MFU prompting you to update.
One way around it would be using something like MIDIPipe or Bome’s to convert the shifted status to whatever you need.
I’m having this same issue with current firmware / software here in 2019.
Can anyone enlighten me on how to make this “shift encoder toggle” actually work the way it seems it was meant to work?
I posted this in another thread. But to get shift encoder hold encoder turns to send CC on ch 5 like the guide says it’s supposed to do, you need the latest firmware, then after upgrading you need to factory reset, then crucially do NOT import settings made before the factory reset as they seem to have the channel implicitly hard coded to ch1. You need to recreate your settings by hand from the factory defaults. Then it works perfectly.
The shift encoder doesn’t work for me either. My track’s input channel shows that it is transmitting via Channel 5 as expected, but a MIDI Monitor device shows it’s transmitting via Channel 1. This seems very odd. I wonder if it’s an issue inside Ableton Live, rather than the Twister, or maybe I have overlooked something?
When I map the shift encoder to a synth parameter, it is indeed transmitting via Channel 1, which means that both the default encoder state and the shift state are transmitting via the same channel and CC#, therefore I’m not able to make use of the shift encoder as intended.
Thanks, that worked for me. However, pertaining to the “shift encoder”, with the last firmware (I’m new),there was a different color for each encoder setting (i.e red for no switch and green for switch) and now the encoder remains in “off” colour all the time, is this correct behavior?
Also, in Cubase, the on encoder (set to toggle) works fine when my EQ is off, but if an eq is on, the light remains on. It will turn on/off as expected from Cubase however.
Add me to the list of people with this problem. Got my twister today. I have updated the firmware to the latest version and did a factory reset. Midi-Ox shows non shifted encoder on channel 1 and shifted encoder on channel 5 but I can’t make it work in any practical application. I’m no midi expert but I’m not sure how this would work anyway, does midi learn get different data from different midi channels?
I go into any VST and do a midi learn. Learn the filter on the non shifted encoder and the resonance on the shifted. The result is that both encoders control both knobs. Not very useful. Anyone have this working? The ability to hold and shift to control a different knob was one of the features that drew me to this controller. Disappointing that this is so problematic.
Possibly your VST is set to a specific midi channel in which case the Shifted encoder, even though is outputting midi channel 5, is rooted to the channel pour VST is on.
Do you happen to use Ableton Live also? DJ TechTools Support told me that this MIDI channel problem “can happen” and that, for example, “it happens a lot with ios/android apps that only read one channel that primary cc’s/notes are sent on”.
A user on KVR forum said that it is “just how Live works” and that “by default, if you load a VST instrument, Live will send the MIDI data to the instrument on MIDI channel 1”.
In any case, I don’t believe the fault lies with the Twister, nor with the VST instrument, but rather it is a problem with Live. The only workaround I have is to configure the VST instrument parameters for display in Live’s panel so that I can then use Live’s own MIDI mapping, instead of the MIDI mapping within the instrument. In this manner, the correct channels are recognised and everything works as intended.
Good call, that is it! Was trying to map U-he Repro with no success. It doesn’t seem to acknowledge different midi channels. Did the same this with operator and wavetable in ableton and no problems. The problem I have now is that most of my VST behave the same way that repro does. Maybe I need to map via ableton rather than midi learn.
