Where are controller-specific color scripts kept?

[Whiskeysaurus]

I've got a midifighter twister and a midi fighter 3D
I'm trying to build a controller preset for a midi fighter 3D to work like the twister. The inputs all work fine with the generic grid mapping ofcourse, but I cannot for the life of me find where to write the MIDI scripts to get effects like color or flashing the LEDs, like the twister grid-> generic playtime grid combo does right out the box.

Also wondering how you've gotten it to show information such as the record arm, as that's not a part of the "Playtime: Slot Transport Action" system at all.

[helgoboss]

Midi Fighter Twister controller preset (virtual control scheme "grid"): https://github.com/helgoboss/helgobox/blob/master/resources/controller-presets/factory/djtechtools/midi-fighter-twister-grid.preset.luau

It uses a feature called "Compartment Lua" that allows you to put Lua code into the compartment that you can then reuse among all mappings in the MIDI scripts: https://github.com/helgoboss/helgobox/blob/master/resources/controller-presets/factory/djtechtools/midi-fighter-twister-lib/compartment-common.luau

All this is not easy to understand right now because there's no docs yet.

[Whiskeysaurus]

Where are these files stored locally? Is it actually possible to replicate this, or is everything in "factory" integrated differently?
I've rewritten the following for the MIDI Fighter 3D:

I've rewritten the following for the MIDI Fighter 3D:

local color_palette: { midi_script.RgbColor } = {
    { r = 255, g = 0, b = 0 },    -- Bright Red (Velocity 13-18)
    { r = 127, g = 0, b = 0 },    -- Dim Red (Velocity 19-24)
    { r = 255, g = 165, b = 0 },  -- Bright Orange (Velocity 25-30)
    { r = 127, g = 82, b = 0 },   -- Dim Orange (Velocity 31-36)
    { r = 255, g = 255, b = 0 },  -- Bright Yellow (Velocity 37-42)
    { r = 127, g = 127, b = 0 },  -- Dim Yellow (Velocity 43-48)
    { r = 191, g = 255, b = 0 },  -- Bright Lime Green (Velocity 49-54)
    { r = 95, g = 127, b = 0 },   -- Dim Lime Green (Velocity 55-60)
    { r = 0, g = 255, b = 0 },    -- Bright Forest Green (Velocity 61-66)
    { r = 0, g = 127, b = 0 },    -- Dim Forest Green (Velocity 67-72)
    { r = 0, g = 255, b = 255 },  -- Bright Cyan (Velocity 73-78)
    { r = 0, g = 127, b = 127 },  -- Dim Cyan (Velocity 79-84)
    { r = 0, g = 0, b = 255 },    -- Bright Blue (Velocity 85-90)
    { r = 0, g = 0, b = 127 },    -- Dim Blue (Velocity 91-96)
    { r = 127, g = 0, b = 255 },  -- Bright Purple (Velocity 97-102)
    { r = 63, g = 0, b = 127 },   -- Dim Purple (Velocity 103-108)
    { r = 255, g = 0, b = 127 },  -- Bright Magenta (Velocity 109-114)
    { r = 127, g = 0, b = 63 },   -- Dim Magenta (Velocity 115-120)
    { r = 255, g = 255, b = 255 },-- Bright White (Velocity 121-127)
}

-- Feedback behaviors for the Midi Fighter 3D
type FeedbackEntry = {
    behavior: number,
    color: number?,
}
local bright = 33  -- Solid light
local pulsing = 45 -- Pulse animation
local blinking = 41 -- Blink animation
local default_color = 0 -- Default color, which can be adapted
local feedback_table: { [string]: FeedbackEntry? } = {
    ["playtime.slot_state.empty"] = {
        behavior = bright,
        color = 19, -- Bright White (Velocity 121-127)
    },
    ["playtime.slot_state.armed"] = {
        behavior = bright,
        color = 0, -- Bright Red (Velocity 13-18)
    },
    ["playtime.slot_state.stopped"] = {
        behavior = bright,
        color = 6, -- Bright Yellow (Velocity 37-42)
    },
    ["playtime.slot_state.playing"] = {
        behavior = pulsing,
        color = 10, -- Bright Cyan (Velocity 73-78)
    },
    ["playtime.slot_state.paused"] = {
        behavior = bright,
        color = 14, -- Bright Purple (Velocity 97-102)
    },
    ["playtime.slot_state.recording"] = {
        behavior = pulsing,
        color = 0, -- Bright Red (Velocity 13-18)
    },
}

[helgoboss]

Press Menu => Preset-related => "Create main/controller compartment preset workspace (including factory presets)" and it will duplicate all factory presets as user presets, including all the extra files you need. Make sure to read the generated README file in that folder.

[Whiskeysaurus]

This seems to only create the presets, when I believe I actually need the controller mappings. Am I missing something?

[helgoboss]

I don't understand what you mean. Can you elaborate? I thought we were talking about presets. Controller presets contain controller compartment mappings, main presets contain main compartment mappings.

[Whiskeysaurus]

Im not clear on the structure of those two things as it relates to this.
What I'm trying to replicate is the midi fighter twisters LED feedback. It translates color to the exact midi messages necessary to display Reaper's colors. I just want to build one that does the same thing for the midi fighter 3D(/spectra)

The midi fighter twister doesn't appear to have a main compartment factory mapping as far as I'm aware. It has controller mappings.

[Whiskeysaurus]

Ohhhh so the actual context menu option is "Create ________ compartment preset workspace (including factory presets)" and it changes only by the single word "controller vs "preset," depending on which compartment you are currently showing.

I get that this section is certainly under construction, but that's a special kind of obscure haha.

[helgoboss]

It's not under construction (the user guide is) and it's also not really uncommon. This technique is called "context-sensitive menus" or "context menus" in user interface design (the context being the currently shown compartment). What's probably a bit uncommon is:

• (1) that the context menu is also accessible as a button, not just via right-click (I tried that before but many users didn't even realize there's a menu ... so having a button is really important)
• (2) that I specifically include the name. Do you think it would be better to just write "Create compartment preset workspace (including factory presets)"? This is something I could easily change without much budget ;)

[Whiskeysaurus]

Well,
A. Nothing about the one unified "menu" suggests that it's context-dependent, or that it switches contexts based on the currently-shown compartments. I can't even find another menu option that is context-dependent. Also, items inside a static submenu very seldom change based on context.
B. An eight-word menu item varying by a single word, which itself has a very confusing definition within this app.
"Controller" vs(?) "main", "controller preset" vs(?) "real mapping", what is and is not a "preset" etc. The language and corresponding UX structure in Realearn is such a wild mess that I assumed it was placeholder, since Playtime's UX is fairly consistent.

Anyways, in the case of your context menus for creating workspaces, if this is actually final language layout, my fix would likely just be to unify them into one option that creates both controller and preset files, conceptualized as a single development environment.

[helgoboss]

Well,
A. Nothing about the one unified "menu" suggests that it's context-dependent, or that it switches contexts based on the currently-shown compartments. I can't even find another menu option that is context-dependent. Also, items inside a static submenu very seldom change based on context.

That's correct and can be attributed to point (1).

There are really many context-dependent entries in that menu though, especially among the upper ones.

B. An eight-word menu item varying by a single word, which itself has a very confusing definition within this app. "Controller" vs(?) "main", "controller preset" vs(?) "real mapping", what is and is not a "preset" etc. The language and corresponding UX structure in Realearn is such a wild mess that I assumed it was placeholder, since Playtime's UX is fairly consistent.

"Controller/Main Compartment" (and derived from that "Controller/Main mapping" and "Controller/Main preset") are very established and logically consistent concepts in ReaLearn. I think your confusion might be partially due to not being familiar with ReaLearn and maybe not having read the relevant parts of the ReaLearn Reference (previously "ReaLearn User Guide"). If this is not true and you did read it, then I'm open to concrete suggestions how to improve the wording. ReaLearn also has a Wiki, in which anybody can contribute.

I should add that ReaLearn is free for everyone. It's a "take-it-as-it-is" gift to all REAPER users. That doesn't mean that it's bad in general. But when it comes to the UX, it's definitely bad compared to Playtime and I don't plan to improve that significantly, at least not in the mid-term. It will maybe never reach the commercial-grade UX of Playtime.

Anyways, in the case of your context menus for creating workspaces, if this is actually final language layout, my fix would likely just be to unify them into one option that creates both controller and preset files, conceptualized as a single development environment.

Nope. Controller and main compartments are totally separate things. A single development workspace is not going to happen. In addition to the ReaLearn Reference, I can recommend this tutorial video which slightly touches ReaLearn's 2 compartments.

What I could do is either:

a. Have 4 non-context-sensitive actions instead of 2 context-sensitive ones
b. Leave them context-sensitive and move them a bit up in the menu (so that they are closer to the other context-sensitive entries). I think that would be a good idea.

[Whiskeysaurus]

Right..,Thanks.