ClearFXSlot Action Doesn't Return to SelectedTrackFXMenu When Surface is Listening To Itself

[FunkybotsEvilTwin]

If a surface is 1) broadcasting, but 2) also listening to itself, and the 3) "Listens To" checkbox for FXMenu is enabled, then the ClearFXSlot action no longer returns to the SelectedTrackFXMenu or TrackFXMenu as expected.

Here's test 1 (control test - works as expected):

1. With no Broadcast/Listen and an empty project in Reaper
2. Create an empty track
3. Load an FX you have a mapping for on said empty track. Make sure you have ClearFXSlot assigned somewhere.
4. Press the plugin button to load the SelectedTrackFXMenu
5. Activate the FX Slot by pressing RotaryPush
6. Press the ClearFXSlot action/button

Result: You return to the SelectedTrackFXMenu

Expected Result: Same.

Test 2:

1. Turn on Broadcast/Listen have the XTouch set to Broadcast and Listen to itself. Check the listen box for FXMenu.
2. Repeat steps 2-6 above exactly the same.

Result: Pressing ClearFXSlot takes you to the track zone.

Expected Result: You return to the SelectedTrackFXMenu

[higginsdragon]

I was able to duplicate this and find the exact function that's causing this - ListenToClearFXZone in control_surface_integrator.h

If there are no broadcaster/listeners in DeclareClearFXZone, it checks the zoneName which is "FXSlot" and if so directly calls ClearFXSlot() which will handle everything as expected

else if (!strcmp("FXSlot", zoneName)) ClearFXSlot();

However, if there are broadcasters/listeners set up, it calls ListenToClearFXZone, which handles it like this:

else if (!strcmp("FXSlot", zoneToClear)) for (auto &listener : listeners_) { if (listener->GetListensToFXMenu()) listener->GoZone(zoneToClear); }

The very first thing GoZone calls is ClearFXMapping(); which works as advertised.

This seems to be deliberate/intended behavior, maybe to avoid recursion? I'd have to dig deeper.

It might better help to know what the user is trying to do, and see their broadcast/listener setup (if there's a specific post the user explains this, feel free to link it.)

I wouldn't want to change any code until I completely understood what is trying to be accomplished with the user's devices.

[FunkybotsEvilTwin]

Hi Higgins, one of the use-cases would be this:

1. X-Touch contains the SelectedTrackFXMenu
2. You're "broadcasting" the FX Map to another surface (example: C4, where the FX will activate)
3. You press ClearFXSlot intending to return to the SelectedTrackFXMenu on the X-Touch

Instead...you essentially end up back home.

You're probably right that it may have been done deliberately to avoid recursion. In conversations with Geoff, he talked about prior iterations of broadcast/listen having pretty complex, ugly code to avoid similar issues. "Broadcaster broadcasts to the listener, which can broadcast back to the broadcaster, which then wants to broadcast right back to the listener."

It's definitely an area of the code where being slow, cautious and deliberate should be encouraged. So no big rush.