X-Touch / X-Touch XT LCD refresh issue with focused FX

RattlesnakeLodge commented 2 years ago

Sir...

I have not had much time to fully test the X-Touch color LCD scribble strips with ReaLearn, but I have started to notice some oddities.

I have adding a mapping schema for basic DAW operation on 3 instances of Realearn, in my monitoring FX chain. These three instances are for my X-Touch, X-Touch extender, and MIDI Fighter Twister. I have it so each one is syncing its compartment parameters with each other. It works flawlessly in basic DAW operation.

Now, I have created three more instances of ReaLearn, tagging them as "Superior". These three are for focused FX mappings. The idea is the mappings in these three will activate when specified FX plugins are in focus. When those plugins are not focused, my control surfaces and MIDI Fighter Twister fall back on the basic DAW operation.

The issue is when pulling up an FX GUI into focus, the X-Touch and X-Touch extender LCDs very quickly "flash" the correct text and colors, but go black within a few milliseconds. Unfocusing the FX plugin also leaves the LCDs black, but only on the X-Touch. The Extender seems to work as expected. Only when I invoke a parameter change tied to display feedback, do the LCD displays refresh. For example, hitting the fader bank button to change parameter 1, thus changing which tracks are represented on each X-Touch channel.

One thing of note: I reverted to basic Mackie and Mackie XT display types at one point, to see if it is the color MIDI messages being the issue. When in Mackie display mode, the upper row / line 1 did not refresh correctly when focusing a plugin, but the bottom row / line 2 did.

I made a quick video to demonstrate, and better explain what this behavior is.

https://photos.app.goo.gl/SP7PgcbwxuEerfno9

All other control and feedback components work as expected, when focusing and unfocusing the FX. All faders, v-pots, v-pot LEDS, buttons and their feedback work. The LCDs are the only ones having issues.

Thanks again in advance for any help with this issue!

helgoboss commented 2 years ago

Hi. Without having looked into this in detail, there are some things that you need to be aware of when using the display sources:

ReaLearn allows you to span multiple displays (Display = <All>) or multiple lines (Line = <Multiline>). If you use this and mix it up with single display sources or single line sources, the things you mention are bound to happen! So make sure you don't mix them.
It's essential to only have one active mapping talking to one display. If multiple active mappings/instances access one display, bad things happen (such as one cancelling out the other).

Sure you don't have those?

RattlesnakeLodge commented 2 years ago

To answer your questions...

All instances of X-Touch / X-Touch Extender have been mapped in the controller compartments, so that it is line 1 and line 2 explicitly. No multi line mappings anywhere.
I was wondering if an active overlap was the root cause. I checked all LCD mappings, and in theory, there should be no overlap. There are no conditions, in which two different set of LCD mappings are in conflict. I say in theory, because I am wondering if there is any millisecond overlap when one set of mappings activate on the "Superior" instances (focused FX), while the other set of mappings are deactivated / overruled by superior instance. Is any of it due to the time it takes for the focused FX to "draw its GUI" versus when it reports itself as being focused?

helgoboss commented 2 years ago

ReaLearn uses a "takeover" mechanism to not run into problems as the one you describe in 2.

Any chance you can reproduce this reliably with a minimal set of mappings?

RattlesnakeLodge commented 2 years ago

Yes, I just did.

In a test scenario, I setup two instances of Realearn. I named them "Test - base (non-Superior)" and "Test - FX (Superior)".

Each instance used X-Touch for control and feedback.
Each instance used the same controller compartment preset.
The controller compartment preset in both had mappings for "Ch 1 - LCD 1" , using "X-Touch Mackie LCD" as display protocol, display 1, line 1. Each mapping had control disabled on the controller compartment mapping, set to feedback only.
The main compartment on "Test - base (non-Superior)" had a mapping to target Track 4, display the track name. Color set to yellow.
The main compartment on "Test - FX (Superior) had a mapping to target a parameter on the FX plugin "UNVEIL", displaying a static text I entered, "100Hz". Color set to cyan. FX must be focused.
The "Test - FX (Superior)" instance has "make instance superior" checked. The "Test - Base (non-Superior)" does not. (triple checked ;-) )

The same outcome occurs. When the FX plugin UNVEIL is not open or focused, the LCD 1 is showing the name of track 4, color is yellow, as directed by "Test - Base (non-Superior)" instance. When I open UNVEIL, I see a quick blip of cyan on LCD 1, then black. I can initiate your Reaper action "Send feedback now to all instances", and the LCD 1 goes from black to its intended Cyan, displaying the text "100Hz". When I close the plugin, the LCD 1 goes black again, instead of reporting track 4's name in yellow.

I made another video demonstrating this specific test.

https://photos.app.goo.gl/LZfvRhVfNpFLYEUh6

helgoboss commented 2 years ago

Thanks. I mean, can you also attach a test project?

RattlesnakeLodge commented 2 years ago

Not sure what you mean by "test project". An .rpp file, exported Lua of my ReaLearn mappings, something else?

helgoboss commented 2 years ago

RPP file is always the best, at least if you don't use the monitoring FX chain.

RattlesnakeLodge commented 2 years ago

I created a very bare test project, re-creating the same scenario from my previous comment. This time I chose ReaEQ for my test case, since everyone with Reaper likely has that FX installed. Same results.

BTW, I DO use the monitoring FX chain, so I am also posting exports of my ReaLearn instances, in case the .rpp file does not contain metadata for the monitoring FX chain.

GitHub apparently has issue with .rpp attachments, so I'm posting a Google Drive link to the .rpp file.

.RPP file https://drive.google.com/file/d/19UEw50neebGmFLIQHGb0aFEqxXgemnnO/view?usp=share_link

Controller Compartment - both instances.txt Main Compartment - X-Touch Test - base.txt Main Compartment - X-Touch Test - FX.txt

helgoboss commented 2 years ago

Thanks, I could reproduce this. ReaLearn seems to miss an event that should make it suspend the non-superior instance. I'll have a look what causes this.

helgoboss commented 2 years ago

Ha, no, it's something else. ReaLearn prevents sending repetitive duplicate feedback to devices (which is good). However, it does that on a per-instance basis. So the "FX" instance remembers that it sent a string "LowShlf" to the X-Touch. When the "base" instance takes over, it sends track name to the device. When the "FX" instance takes over again, it still remembers having sent "LowShlf" and doesn't send it anymore. I'm not 100% sure it's your bug but it is one for sure. Fixing.

RattlesnakeLodge commented 2 years ago

Just tested on new "pre-10". Still the same behavior, unfortunately. :-( I setup the same test scenario from the project I sent you.

I also noticed this same behavior within the same instance. I tried to do something funky, and trigger different mappings with virtual source "Ch 1 - LCD line 1"...

Dummy target, fixed text "Monitor", color WHITE when a particular mapping for Track Monitor mode OFF had a target value of 1
Dummy target, fixed text "Monitor", color WHITE when a particular mapping for Track Monitor mode NORMAL had a target value of 1
Dummy target, fixed text "Monitor", color RED when a particular mapping for Track Monitor mode TAPE had a target value of 1

To compound this, I noticed the same flicker then off issue on the V-Pot LEDs, when I mapped them like the same scenario above. Different values on three Ch 1 V-Pot LED mappings , active only when a particular track monitor mode returned a value of 1. Not sure if this is related, but thought I would record the behavior.

I'm no developer, but I'm wondering if ReaLearn is trying to send new feedback before the "Reset feedback when releasing source" command has finished executing. In other words, possibly an overlap of resetting old feedback and activating new feedback? I tried playing around with disabling "Reset feedback..." in Options. While it's a big pain to keep "Reset feedback" unchecked, disabling it did in fact remedy the test issue.

BTW, LOVE the next and previous buttons on the bottom of the mappings. Huge time-saver! :-)

helgoboss commented 2 years ago

Can you send me this very simple one-instance setup as RPP? The simpler the better.

RattlesnakeLodge commented 2 years ago

Attaching Google Drive link to .rpp file and controller/main compartment exports at the bottom of this comment.

I think I may have possibly stumbled upon the root cause, looking at the real feedback logs.

In my new test scenario, I set up a browse mappings case like the one I previously described. I have a group for each track input monitor mode (Off, Normal, Tape), and a browse mappings target assigned to control source Ch 1 V-Pot. Feedback sources include V-Pot LEDS (single mode), LCD line 1 with static text but different colors, and LCD 2 with different text.

When I make the FIRST positive increment (from mapping 1 to mapping 2) on the browse mappings control (turn V-Pot clockwise by one step), it activates the next mapping in the group as expected. The LCD very briefly shows the new color, but quickly goes black. From the feedback logs, it appears the correct LCD feedback is sent, but immediately reset/cleared.

When I make a NEGATIVE increment, the correct feedback is sent, and no reset/clear MIDI message is sent. LCDs display as they should.

When I turned off "Reset feedback when source is released", everything behaves as it should.

Real Feedback Logs...

NOW, with "Reset feedback when releasing source" turned off...

Positive increment...

Negative increment...

As I stated in my previous message, it would be great if I could continue to use the "Reset feedback..." option, so I don't have to create a bunch of "Off" mappings for LCDs, V-Pot LEDs, Buttons, and Faders when they're not in use. But if that is the culprit and there is no way to solve this issue, I will make do. :-) I do it in CSI with explicit "NoAction" statements.

Google Drive Link to test project...

https://drive.google.com/drive/folders/1k2GqasJKJhnBrk_fL672XRxHVL4Y8JxD?usp=share_link

RattlesnakeLodge commented 1 year ago

Any updates on this issue?

helgoboss commented 1 year ago

Sorry, I'll look at this bug eventually but I can't promise a date. There's a lot of stuff in the pipeline and Playtime has more priority for me at the moment ... Playtime means fun + business, fixing subtle ReaLearn bugs means no fun + doing things for free ;)

helgoboss / helgobox

X-Touch / X-Touch XT LCD refresh issue with focused FX #727