Changing MIDI Fighter Twister LED colors using ReaLearn?

[stereokai]

Currently I have the MIDI Fighter Twister set up using its built-in banks function, where I have a different layout and colors in every bank.

I would like to use the virtual mapping as you recommend in your guides, however, I would prefer not to use my color layouts.

In the guide for MIDI Twister, it says it's possible to control the colored LEDs using by sending MIDI CCs to the Twister, like so:

Can ReaLearn be configured to send multiple MIDI CCs when changing a mapping to configure the colors layout of the buttons?

Thanks!

[helgoboss]

This is something I want to support with #113, which is high on my todo list (currently still working on OSC). My rough plan to support this use case (and a multitude of other ones) is to implement the following concept:

• Provide a button "Details" (or similarly-named) in the mapping source section which opens up a small window containing mostly a text area.
• This text area allows you to enter key-value pairs such as:

  mft.rgb_color: 54
  midi.send_on_activate: "F0 43 10 4C 02 01 5B 7F F7"

• ReaLearn itself would read these key-value pairs and handle them if there's a handler.
• In the beginning I plan to implement handlers for exactly the keys that you can see in the above example snippet (although details might still change). The handlers will be hard-coded into ReaLearn, but in a maintainable way. Example handlers:
  • mft.rgb_color: ReaLearn will translate the value into the correct Twister-specific MIDI message to be sent whenever that mapping gets active.
  • midi.send_on_activate: ReaLearn will interpret this as raw MIDI data (in this case sys-ex) and send it whenever the mapping gets active.
• In order to support also more complicated scenarios, this shouldn't be just a flat key-value list but allow for deeply nested data. That's why I plan to not use simple INI file syntax but support YAML - which is as expressive as JSON while at the same time less verbose to write for humans. Another advantage of YAML is that users who are not into programming can still write this as a simple key-value list (such as in the example above) - everybody should be able to understand that.
• Important: I prefer YAML over a scripting language because it's declarative. While a full-blown scripting language would give the user great power, it would severely limit the ability of ReaLearn to make future optimizations and improvements. It's also more extensible and easier for most users. Plus, nothing would prevent one in future to add a key that contains a little script as value. Plus, everything being YAML means that in future a UI could be made for these sort of things.

Best of all: It's very straightforward to implement this. And it provides a simple but scaleable framework for future extension. Writing handlers should be easy.

Your last use case of sending multiple CCs on mapping init could be done by using midi.send_on_activate but obviously for most people, entering raw MIDI data would be too difficult. Therefore the handler of this key could support also an alternative way of writing the init MIDI messages, something like the following:

midi.send_on_activate:
  - cc: [0, 7, 50]
  - cc: [0, 64, 2]

I'll probably start with working on that next week. If you have some feedback/comments/ideas, let me know.

[stereokai]

@helgoboss I like this idea. Sounds like a sensible and flexible solution.

• midi.send_on_activate: ReaLearn will interpret this as raw MIDI data (in this case sys-ex) and send it whenever the mapping gets active.
• mft.rgb_color: ReaLearn will translate the value into the correct Twister-specific MIDI message to be sent whenever that mapping gets active.

Best of all: It's very straightforward to implement this. And it provides a simple but scaleable framework for future extension. Writing handlers should be easy.

Agree, but...

Are you sure you want to implement controller specific properties (that under the hood are generic MIDI)?
There are 2 reasons for my question:

1. While I like the solution and find it highly flexible, it is not the most user friendly. Perhaps it is accessible to software devs like you and me, but to the everyday musician/producer might be too intimidating to approach. Have you considered a UI on top of this feature? It's my opinion that in general, your users should learn how their controllers' work, not (just) you. So maybe something like this:

2. Supporting those specific rules in the long run will shape into an infinite maintenance hassle. Adding more controllers, updating the key-to-MIDI "translations" if and when controllers receive firmware updates, deciding which 3rd party features to include and which not. This in my eyes is even less justified if you go for a text only solution - it's super flexible but will simply be too complicated for most people to use. ReaLearn is already very rich and has a lot to offer - and a lot to learn as well. Try to think about it from you users' perspective.

* Important: I prefer YAML...

You're preaching to the choir here :)

[helgoboss]

Agree, but...

Are you sure you want to implement controller specific properties (that under the hood are generic MIDI)?
There are 2 reasons for my question:

1. While I like the solution and find it highly flexible, it is not the most user friendly. Perhaps it is accessible to software devs like you and me, but to the everyday musician/producer might be too intimidating to approach. Have you considered a UI on top of this feature? It's my opinion that in general, your users should learn how their controllers' work, not (just) you. So maybe something like this:

Writing such a GUI can be done on top of that, totally independently. I'm providing the basic foundation for that. That's what I meant when writing "everything being YAML means that in future a UI could be made for these sort of things.".

One thing I'm rather sure about is that I'm not going to write this sort of GUI as part of ReaLearn's core, simply because of the fact that the underlying UI technology makes this too hard. I think you are coming from a web development perspective where building a GUI such as the one you showed is very easy. Doing this with the raw Win32 API / SWELL is pain. Just look at my GUI code and you will see why.

I develop ReaLearn for free for idealistic reasons and for the fun of it. Working on its UI often takes the fun out of it but I keep going because some things really need a GUI to be instantly and intuitively usable. However, things like setting light colors, initializing controllers ... that sounds a lot like configuration work to me, it's not something that needs to be done instantly and all the time. So I don't really see an urgent need for providing a very nice GUI for that - this would be just a small GUI-less part of ReaLearn. While I think user friendliness is important, I also think that one should not underestimate what a user can do. Writing a simple key value pair such as mft.rgb_color: 50 should be doable by everyone. Could be part of a preset also so it doesn't always have to be repeated. Or maybe a little UI where on the left side one can enter the keys and on the right side the values.

That said, having a GUI for things like this would of course still be better than not having one. This is actually one part where users with programming skills could contribute: It would be cool if someone could write little browser-based UI components that generate e.g. some aspects of the YAML: A GUI such as the one you sketched, or one to generate bezier curves. I could provide a way to integrate that into ReaLearn, e.g. via WebView.

1. Supporting those specific rules in the long run will shape into an infinite maintenance hassle. Adding more controllers, updating the key-to-MIDI "translations" if and when controllers receive firmware updates, deciding which 3rd party features to include and which not. This in my eyes is even less justified if you go for a text only solution - it's super flexible but will simply be too complicated for most people to use. ReaLearn is already very rich and has a lot to offer - and a lot to learn as well. Try to think about it from you users' perspective.

I think even for the normal user, writing a simple mft.rgb_color: 50 requires less knowledge and effort than clicking together a list of MIDI messages using a generic UI. And this is a simple example ... just imagine you need to send sys-ex. From a user-friendliness perspective, I think it's desireable to have dedicated support for features of a particular controller because the user wouldn't need to look up the specific MIDI messages - which can be very troublesome, often not even documented. And if their controller feature is not supported or a new firmware broke things (which should be the exception), one could still resort to the generic MIDI way.

Concerning potential maintainance issues, organizing the code in the right way could prevent most of the maintenance hassle. The hassle that remains is just what it takes to provide such a feature. And even if just the handful of controllers that I own are supported in this way, it would be already better than no support at all. That's how I see it.

[helgoboss]

Note to self: #113 (the generic YAML thing) is implemented. The more controller-specific "RGB color" support discussed in this ticket would be most useful if it can somehow detect which control element the mapping actually is associated with so that we can really just write mft.rgb_color: 50 and don't need to write mft.encoder_1_2.rgb_color: 50.

[stereokai]

Hey, totally missed your post from 3 weeks ago. Must say, you raise pretty sensible points there, can't really argue with them :) The (default?) idea that I had of a dedicated UI is indeed compelling, but most definitely the greater picture as you presented it certainly pushes me to join the camp of your minimalistic and elegant YAML, text based solution. Minimum viable product, minimum time spent. Well done.

so that we can really just write mft.rgb_color: 50 and don't need to write mft.encoder_1_2.rgb_color: 50.

That should be rather easy. The way I see it, mft.rgb_color: 50 would translate to F0 B1 00 32 F7. From end to start the bytes are:

• F7 - hex for color code 50 (by the way, 0 and 127 both turn the color off. The lit colors are between 1-126)
• 00 - the CC number - is the control identifier. That can be pulled out of the mapping
• B1 - Channel number - in this case channel 2. These are by default channel 2 on MFT, but unfortunately can be reconfigured per button by the user using the MFT configuration utility. This is the only problematic part, because if the mapping is bound to the rotary encoder in place of the button, you can't pull this info out of the mapping. Might as well hardcode it? Or perhaps like earlier, you have another creative solution ;)

Thought I'd let you know though, I gave the new Advanced Settings feature a try. However, for some reason, it wasn't working. This SysEx line for example, is supposed to paint the first two knobs on the MFT green and yellow, respectively: F0 B1 00 36 B1 01 3F F7. I tried it out with a separate MIDI tool, and verified it to be working.

Unfortunately, trying out the new feature using the following configuration did not change the colors as expected:

---
on_activate:
  send_midi_feedback:
    - raw: F0 B1 00 36 B1 01 3F F7

I tried the following ways to trigger a mapping: Preset loading/unloading, Conditional activation, Target condition as well as just toggling the feedback checkbox as recommended, but nothing triggered the color change in the MFT. I double checked that the feedback was still working with other mappings. I also tried the same code, again with no result using on_deactivate. Probably I missed something in the guide?

[helgoboss]

The MFT doesn't need/want sys-ex for that:

---
on_activate:
  send_midi_feedback:
    - raw: B1 00 32

This is a normal control-change message (0xB0 is the status byte of a CC message on channel 1).

It's surprising that this works with another sys-ex tool.

[stereokai]

@helgoboss Yep, that totally works. Thanks.

It's surprising that this works with another sys-ex tool.

The tool is called "Pocket MIDI", if you're interested.

[stereokai]

@helgoboss I wrote a tool for designing MIDI Fighter Twister color layouts. It makes it easy peasy to create color banks to use with ReaLearn and makes this feature even more attractive now :)

I hope you find it useful!

https://www.stereokai.com/midi-fighter-twister-color-designer/

[helgoboss]

@stereokai Very cool, the idea of using the controller itself to modify the colors! Playful way of changing them :) In my case, it doesn't work because I have all encoders switched to relative control. Any chance you could support relative messages?

[stereokai]

Yeah sure, can you share/explain how ReaLearn identifies if a control is absolute or relative? That would be helpful :)

[helgoboss]

It's only a heuristic because there's no reliable way to detect it, not sure if you want to go into that. But here's the code that ReaLearn's learn function uses to guess among all popular encoder types (MFT only has "Encoder 2" type): https://github.com/helgoboss/realearn/blob/master/main/src/domain/midi_source_scanner.rs#L240-L240. The values parameter is an accumulation of all message "data 2 bytes" that arrived within a certain time slot.

An alternative could be to provide another dropdown menu / checkbox that lets users choose between Absolute and Relative.

[stereokai]

If it's good enough for you, it's good enough for me :)

I read the code. Since I am not familiar with Rust yet, I'd like to ask, how many input values are you checking against in this heuristic? And for type 2 encoder, why are you checking against 57-71 when the values set in relative mode on the MFT are 63 and 65?

[helgoboss]

I start a timer on the first incoming message and stop either if 10 messages are collected or 250ms are over. If you really want to do the same, RxJS is great in doing this :)

I check for 57 - 71 in order to also catch slightly accelerated encoder moves (MFT for example supports this, optionally).

[stereokai]

Yes I'm familiar with RxJS, but I'm trying to keep this project as barebones as possible :)

Accelerated encoder moves? I am not familiar with this feature. How do you activate it on the MFT?