Bug: when used in custom actions, OSARA: Mute next message from OSARA doesn't mute reports from REAPER toggles

[ScottChesworth]

Encountered a weird thing on Mac, @RDMurray has confirmed it also impacts windows:

1. Create a custom action with "OSARA: Mute next message from OSARA" followed by any OSARA action that reports.
2. Bind your new custom action to a keystroke and test it, you should find all is well.
3. Now create another custom action, this time with "OSARA: Mute next message from OSARA" being followed by a REAPER toggle action.
4. Bind that to a keystroke, and if what I encountered holds up, that'll still report. It shouldn't.

[TimNoonanVoice]

Yes, it is Very odd.

I created a custom action containing

OSARA: Mute next message from OSARA And OSARA: Toggle Report FX when moving to tracks/takes

I assigned it to ctrl-shift-m.

1. When I use the keystroke I hear nothing,

2. but then, when I use the arrow keys to move down a track, it is silent.

3. When I move back to the track with FX on it, I find the toggle
   Command has not actually been acted upon, and the FX details are still announced.

Tim

On 8 Jul 2023, at 10:54 am, ScottChesworth @.***> wrote:

Encountered a weird thing on Mac just now:

Create a custom action with "OSARA: Mute next message from OSARA" followed by any OSARA action that reports. Bind your new custom action to a keystroke and test it, you should find all is well. Now create another custom action, this time with "OSARA: Mute next message from OSARA" being followed by a REAPER toggle action. Bind that to a keystroke, and if what I encountered holds up, that'll still report. On Windows, the "OSARA: Mute next message from OSARA" action seems to be working reliably. Is it a known thing that this performs differently on Mac? — Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/914, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGNKY267GGJWYUXFWQQL5ETXPCVURANCNFSM6AAAAAA2CN6ZN4. You are receiving this because you are subscribed to this thread.

[TimNoonanVoice]

Yes, it is Very odd.

Here it seems that if the mute action is employed that the toggle action immediately following it doesn't get executed:

However, just running and closing on the FX toggle action does work here though.

I created a custom action containing

OSARA: Mute next message from OSARA And OSARA: Toggle Report FX when moving to tracks/takes

I assigned it to ctrl-shift-m.

1. When I use the keystroke I hear nothing,

2. but then, when I use the arrow keys to move down a track, it is silent.

3. When I move back to the track with FX on it, I find the toggle
   Command has not actually been acted upon, and the FX details are still announced.

4. If I Run and close on the custom action, the same happens, so unsure if this is associated with a keystroke assignment.

Tim

On 8 Jul 2023, at 10:54 am, ScottChesworth @.***> wrote:

Encountered a weird thing on Mac just now:

Create a custom action with "OSARA: Mute next message from OSARA" followed by any OSARA action that reports. Bind your new custom action to a keystroke and test it, you should find all is well. Now create another custom action, this time with "OSARA: Mute next message from OSARA" being followed by a REAPER toggle action. Bind that to a keystroke, and if what I encountered holds up, that'll still report. On Windows, the "OSARA: Mute next message from OSARA" action seems to be working reliably. Is it a known thing that this performs differently on Mac? — Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/914, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGNKY267GGJWYUXFWQQL5ETXPCVURANCNFSM6AAAAAA2CN6ZN4. You are receiving this because you are subscribed to this thread.

[jcsteh]

I'm not sure why Windows and Mac are different, nor why the action might not execute sometimes on Mac. However, it does look to me like we might not be clearing the mute next message flag on either platform for toggle messages.

Scott, if you look where we call handleToggleCommand, you'll see that we don't set muteNextMessage to false before returning. In contrast, we do set that to false above for setting and post commands.

I'm not sure if this is the bug and I don't recall whether there's some reason this wasn't done in the first place. However, it's definitely a place to start looking.

Failing that, I'll try to dig into this when I have some time.

[RDMurray]

This is strange. I honestly can't remember why I didn't just set MuteNextMessage to false before returning from outputMessage. I've got family visiting today, but I'll definitely take a look at it later.

[jcsteh]

Oh yeah, I guess that could work too. I guess there's a chance that a command could output two messages accidentally, but that would be problematic anyway, since the user would miss the first message.

[RDMurray]

I just can't get my head around why I didn't do that instead of sprinkling MuteNextMessage=false all over handleCommand. 🤯

I also can't figure out how it would affect mac differently.

[jcsteh]

Taking a wild guess, there might be some other action that triggers on Mac first before the actual toggle action, so the mute next message was applying to that first action instead of the toggle action. But what other action? And why only on Mac?

[RDMurray]

Okay I tested on mac and windows and got the same result on both. OSARA toggles don't work at all in custom actions. possibly because the custom action itself is being caught by handleToggleCommand, so that when handleCommand is called with the OSARA action, isHandlingCommand is true and handleCommand returns false resulting in nothing happening.

[RDMurray]

There's also the fact that HandleMainCommandFallback doesn't call handleSettingCommand. That's easy to fix but I think we'll still have the problem above.

[RDMurray]

@jcsteh Here's my proposed solution. I wanted to run it by you before going ahead.

• make handleMainCommandFallback call handleCommand to avoid duplication
• split commandsMap into Osara commands and Reaper commands
• In handleCommand process Osara commands before the re-entrancy check to make sure they always run, even when they are in a custom action that is currently being handled by handleToggleCommand.

[jcsteh]

* make `handleMainCommandFallback` call `handleCommand` to avoid duplication

This makes me wonder why I split these out in the first place. I'd like to believe I did it for a good reason, but if so, I can't remember what it was. Maybe it was just that back when I did it, handleCommand was a lot less complex, so running that entire function when we can only handle one section in the fallback didn't make sense to me. Anyway, this proposal seems sensible if it works.

* split `commandsMap` into Osara commands and Reaper commands

This is probably less confusing anyway.

* In `handleCommand` process Osara commands before the re-entrancy check to make sure they always run, even when they are in a custom action that is currently being handled by `handleToggleCommand`.

That would fix the problem. But should we even be handling custom actions in handleToggleCommand at all? I guess they can be reported by the generic toggle handling. On the other hand, we don't provide any feedback for other custom actions, so why should we do so for custom actions which happen to include toggles?

If we did decide to exclude custom actions from handleToggleCommand and if we can find a way to achieve that, that would be a much simpler fix.

[jcsteh]

I think there might be a couple of issues at play here. Let's get clear steps to reproduce for any issues and then we can figure out a solution or solutions.