Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Bug Reports

Reply
 
Thread Tools Display Modes
Old 05-31-2024, 06:20 PM   #1
LetsGoBrandon
Human being with feelings
 
Join Date: Oct 2021
Posts: 36
Default [17.6] SetTrackUIVolume touch status instantly reset despite "bool done" set to false

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:
Code:
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
LetsGoBrandon is offline   Reply With Quote
Old 06-01-2024, 03:13 AM   #2
odedd
Human being with feelings
 
Join Date: Dec 2019
Posts: 263
Default

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.
__________________
Send Buddy | Stem Manager | Project Archiver
odedd is offline   Reply With Quote
Old 06-28-2024, 03:43 AM   #3
LetsGoBrandon
Human being with feelings
 
Join Date: Oct 2021
Posts: 36
Default

Quote:
Originally Posted by odedd View Post
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.

Last edited by LetsGoBrandon; 06-28-2024 at 02:57 PM.
LetsGoBrandon is offline   Reply With Quote
Old 06-29-2024, 06:46 PM   #4
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,863
Default

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.

Last edited by Justin; 06-29-2024 at 07:34 PM.
Justin is offline   Reply With Quote
Old 07-01-2024, 01:30 AM   #5
LetsGoBrandon
Human being with feelings
 
Join Date: Oct 2021
Posts: 36
Default

Quote:
Originally Posted by Justin View Post
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 is offline   Reply With Quote
Old 07-01-2024, 01:42 AM   #6
LetsGoBrandon
Human being with feelings
 
Join Date: Oct 2021
Posts: 36
Default

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.
LetsGoBrandon is offline   Reply With Quote
Old 07-01-2024, 10:24 AM   #7
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,863
Default

Quote:
Originally Posted by LetsGoBrandon View Post
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).
Justin is offline   Reply With Quote
Old 07-01-2024, 04:44 PM   #8
LetsGoBrandon
Human being with feelings
 
Join Date: Oct 2021
Posts: 36
Default

Quote:
Originally Posted by Justin View Post
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.
LetsGoBrandon is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 02:46 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.