[17.6] SetTrackUIVolume touch status instantly reset despite "bool done" set to false

[LetsGoBrandon]

Reaper Version: 17.6
OS: Windows 10

Reproduction steps:
1. Create one track.
2. Create a volume envelope, set automation mode to "touch".
3. Record some automation of the volume
4. Reset and run the following Lua script:

reaper.SetTrackUIVolume(reaper.GetTrack(0, 0), 0, false, false, 0)

There appears to be a bug where a volume control instantly becomes untouched despite "done" being set to false. The same thing happens with it set to true, so there is no affective difference between both settings due to the potential bug.

This causes issues with calling SetTrackUIVolume while play is active on a touch automated track volume. Repeated calls have an inherent race condition if done in rapid succession, causing the volume to randomly leave write mode.

Other mediaTrack UI setter methods may be affected

[odedd]

I just ran into it on my own.
I can confirm it happens at with reaper.SetTrackUIVolume() and reaper.SetTrackUIPan(), and maybe other track UI functions, however it does not happen in the TrackSendUI* functions (such as reaper.SetTrackSendUIVol()).

This goes back to v6.71 when the SetTrackUI* functions were introduced.

Note this is unrelated to this other issue I reported today.

[LetsGoBrandon]

Originally Posted by odedd

I just ran into it on my own.
I can confirm it happens at with reaper.SetTrackUIVolume() and reaper.SetTrackUIPan(), and maybe other track UI functions, however it does not happen in the TrackSendUI* functions (such as reaper.SetTrackSendUIVol()).

This goes back to v6.71 when the SetTrackUI* functions were introduced.

Note this is unrelated to this other issue I reported today.

I used the behavior with reaper actions triggering touch to reverse engineer how the function we are discussing would work. It turns out that in windows this particular API call is using windows SetTimer just like the automation lane reaper actions, that initiate touch (such as "set active fader" or "Decrease active fader" ect).

When I wrap the window procedures in reaper, they always intercept a WM_TIMER message when untouch happens (when touch leaves write mode). SetTrackUI* functions also begin a timer, but those timers expire instantly. This has to be a bug. Rather than automation being carried out, the timer expires right away causing lots of missed point overwrites and all sorts of problems. It also appears that its blocking itself when called in rapid succession. Like it thinks it needs to wait longer than its own timer is allowing.

This needs to be forwarded to the devs.

EDIT: The timers seem internal to reaper. They all share the same global setTimer id, but reaper keeps track of internal counters.

[Justin]

Yeah, these APIs do not set the touch state exactly, the 'done' flag refers to whether an undo point is added. We will look at extending them to affect touch state, or at adding another API to allow setting touch state via ReaScript (it currently requires you to use a C++ interface to override touch states).

Edit: looks like we can give it a temporary-touch (which you can renew by repeatedly calling the API). Though it's unclear what this might break, script-wise. Might have to make it opt-in. TBD in the +dev builds.

[LetsGoBrandon]

Originally Posted by Justin

Yeah, these APIs do not set the touch state exactly, the 'done' flag refers to whether an undo point is added. We will look at extending them to affect touch state, or at adding another API to allow setting touch state via ReaScript (it currently requires you to use a C++ interface to override touch states).

Edit: looks like we can give it a temporary-touch (which you can renew by repeatedly calling the API). Though it's unclear what this might break, script-wise. Might have to make it opt-in. TBD in the +dev builds.

Where in the c++ interface can you override touch states? I've scanned the C api a lot and I cant seem to find it.

Unless of course you mean touching through OSC, which as far as I can tell only supports a few things.

[LetsGoBrandon]

Btw Justin,

I have figured out a clever solution for touching envelopes in another thread: https://forum.cockos.com/showthread.php?t=291665

The downside is the envelope cannot be hidden so it overrides that preference during automation writing. But it seems to work pretty good, and is not spamming envelope points or dealing with race conditions.

It uses the automation lane actions, in particular decrease or increase a tiny bit. But first you save the affected controls value (for instance, the track UI volume). That way you can restore it after you run the action through the API.

This touches the control linked to the fader for a second, and then you can just repeat calls using defer or a timer. If you stop repeating and toggling recarm on that envelope it untouches it.

[Justin]

Originally Posted by LetsGoBrandon

Where in the c++ interface can you override touch states? I've scanned the C api a lot and I cant seem to find it.

Unless of course you mean touching through OSC, which as far as I can tell only supports a few things.

You have to do it by creating a control surface (you can register a hidden one) and implementing its touch methods. but anyway, in the latest +dev builds the behavior should be fixed (touch will be set temporarily for up to 1000ms or until called with done=true).

[LetsGoBrandon]

Originally Posted by Justin

You have to do it by creating a control surface (you can register a hidden one) and implementing its touch methods. but anyway, in the latest +dev builds the behavior should be fixed (touch will be set temporarily for up to 1000ms or until called with done=true).

I don't want to derail the thread; I'm very new to the reaper API, but I looked at reaper_plugin.h

https://github.com/justinfrankel/rea...eaper_plugin.h

I looked over it before, but maybe I missed that GetTouchState hooks when reaper is deciding to enable touch or not? Is isPan an enumeration for volume, pan, width?

I originally thought they were all event handlers, but I guess I missed some have return values making them hooks.