I purchased midi fighter twister to find out that LEDs are not RGB! You send a color code from 1 to 126 which leaves me with very limited set of colors (I can differentiate between 6-8 colors on the rainbow, otherwise it’s too close).
However, when we’re, for example, setting the device to bootloader mode, we can see white LEDS which means it supports arbitrary RGB, it’s just not exposed in midi!
Having control over red/green/blue separately would allow almost an infinite amount of colors + exact mapping of track colors e.g. in ableton, and many other tricks.
Can we get an option to send r, g, and b individually? Maybe in the driver utility you would select the input channel for different settings (it was very confusing to find that you need to send stuff to channel 2 to set brightness).
This has always been considered and we settled with the predefined values for easier mapping. That said, that door is not fully closed but in order to get proper white you need a dedicated white LED, which Twister lacks, so we don’t have white as one of the values since it doesn’t look consistent enough.
Is it mainly getting the RGB bit to match an Ableton track what you are after?
Yes, matching Ableton track colors exactly is the main goal. The current preset colors are okay, but often I have to settle for something ‘close enough’ which defeats the purpose of visual feedback. regarding the white LED issue: I think most users would happily accept an imperfect ‘mixed white’ if it meant gaining access to the full RGB spectrum for all other hues
Besides ableton, there are a lot more uses (e.g. color coding stuff on my pedalboard, and there is at least 17 things that need unique colors)
Not exposing colors while hardware supports it, is a very strange decision, to be honest. I completely don’t mind colors being not very accurate (they are slightly varying anyway), just give me more colors
The reasoning behind not exposing it as addressable RGB was to keep remapping more accessible since all color commands will stay on the same CC/Note as the button. I do agree that while we do want to keep that approach we shouldn’t limit power users and this would unlock new use cases like the ones you mention.
These images show what would it would look like with the current firmware if all LEDs were set to white (available by tweaking the Twister plugin within the app). Aside from the pink/purple hue which might be mitigated by tweaking the RGB values for this specific color you can see some have a warmer tone (varies per unit) which is really highlighted when trying to get white and it’s nowhere near the brightness of the dot rings.
Something we can do relatively quickly would be testing the color palette the MF64 and other 64 grid controllers use which was designed to mimic Live’s clip colors. Would that do the trick.
@rasiel@Danielle77130 Can you guys give this test firmware a go? It has the same color palette as the image I shared before and some white correction applied.
In order to load this to your Twisters do as follows:
Connect a single Twister directly to your computer (no hubs)
Close any MIDI related software (if on Windows)
Open the MFU
Click on Tools>Midi Fighter>Load Custom Firmware>For a Twister
Select the .hex file containted in the zipped file above
Let the MFU do it’s thing
Note: Make sure you set the OFF color for each RGB bean to black and the ON color to the last value, that way it will use the full range. And keep in mind the color swatch on the MFU will not match anymore.
These are my units post white fix (they look a tad less pink IRL). Left unit is pretty new, the other one is probably almost 10y now but you guys can see that the same LEDs are inconsistent on it
omg! this is the best support ever! I loaded it, gonna figure out how to set the colors now. I can see that value animations are not there anymore (or they’re on a different channel), but in case i don’t find them i can emulate blinking by sending values (btw i use blinking to highlight the parameter that a foot pedal controls)
Yeah I didn’t figure out yet how to get the colors I want, I’ll try again tomorrow (you said I should send OFF somewhere. I tried sending zeroes to all channels before and 48 (max brightness?) to the first animation channel)
In terms of controls, I think it’s flawless and there are no problems so far, but I can describe some thoughts
I always have all knobs in the “non-precise mode” - it’s the most quick to use. But some knobs I would have a more precise control (for example, when there are a lot of discrete values for the controlled parameter. Or there is tempo knob). For these I would set them to “high resolution”. But everything is set up programmatically (knobs point at different things depending on state), so I would need to be able to set knob mode with a midi message too. Not a big deal, though.
For some knobs (e.g. tempo, or some lfo frequency with high range) I would like to have higher resolution than 0-127 with slower turning. I was considering trying to write some hack to update knob value after turning so that maybe I can make it very precise.
I have both ring animation and rgb led animation at the same time - and if these animations are at the same knob - it’s not supported by device, so I send 0 and color every second.
If animation is disabled while it’s turned off, it ends up in half lit state. So I have to update it after turning it off. I guess it’s fine.
I have a different function when I hold the button and turn the knob. I had to make a dead zone filter because it registers rotation when I press it and don’t intend intend to rotate.
I rarely stumble on a music-related device without bugs and hardware issues. Nice job.
@rasiel what software are you mapping it to?
For stuff like tempo/lfo that need really fine control I’d use either an ENC message rather than a CC to get more than 128 steps and perhaps use Velocity as the sensitivity setting so it’s finer if the encoder is turned slow but responsive for quick cuts.
Since it looks like you have an intense map going I’d suggest first starting fresh to set the colors and then take those settings to your current build to ensure no cross talk with animations, etc.
RE: OFF state. The off color should be sent in the mfu, you shouldn’t need to send that back every second. Just when the control it’s mapped to enters it’s off state. You should also be sending an animation message with vel0 so you tell the unit the led should be solid rather than stopped mid animation.
14bit midi (0-255) is one of the things I have at the top of my list for Twister.
I also found someone on this forum changes knob type dynamically via sysex, gonna try that as well.
Good point with starting fresh! Because at some points I see the colors I want, but then it’s either all green or all blue
My setup is:
1. twister+some foot controllers
2. My custom vst plugin for Reaper that manages midi messages, presets, knobs/button functions, visual feedback, and reaper tracks and fx. They can be toggled and rerouted via this VST so that I can have quick access to VST plugins on jams without mouse clicking. For example, I have a guitar synth effect, and there are 2 knobs that are responsible for “page” for other knobs, and they decide what two sets of 6 knobs do: e.g. there is an osc1 page, osc2 page, amp page, and so on. Very convenient (and also a lot fun to design hahaha)
3. a bunch of Reaper tracks with VST plugins that accept midi messages and send audio to each other, defined by the VST plugin above. Plugins need to be disabled and enabled automatically so that I can have an insane amount of them with just 3ms latency without crackles.
Colors work well now. A bit pity that it’s not possible to get magentas, purples, purple-blue, there are a lot of very similar colors, but now it’s better because everything got it’s unique color. Value highlight bleeds a bit into the LED btw
I read that thread about SysEx messages - they didn’t succeed. Well, having different types of encoder setting at the same time is not critical for me, but that would be nice
thanks