Fader Volume Doesn't Stop Ramping

[muzicman82]

Hi Mat,

I'm randomly seeing an issue sometimes where when I pulse the fader module vol up or down, the level will continuously ramp. The hold till repeat time is 1s and repeat time is 0.5s, but I'm only quickly pulsing the up/down.

Anything I should check out here?

[MatKlucznyk]

Any chance this is on a tst-902?

[muzicman82]

No, it's happening on TSW-760's but also when I open the VTZ as XPANEL. The controls are standard buttons but they are in subpage reference lists.

[MatKlucznyk]

Technically the ramp function is not threadsafe so if the press/release events fire very quickly its possible the release will cancel the ramp before it begins. I'll look into this.

[muzicman82]

Thank you sir. I haven't looked at the protocol close enough and wasn't sure if your module was doing ramp only or setting the up/down by a static value based on the current value so that they don't actually use ramp.

[MatKlucznyk]

From testing in debuger the branch I just added should hopefully fix this. Could you give this a go in your environment before I merge and close the issue? You just need the QsysFader.usp. You can copy the text from here and recompile in your project.

[muzicman82]

Yes, let me see if I can remote into the client site and do some remote testing. May not be until tomorrow but I'll give it a go ASAP. Obviously, when I tried to replicate the bug to do a screen capture, I couldn't make it happen, but it does it when it wants.

[MatKlucznyk]

The change is in the branch fix-issue-#35-fader-volume-doesnt-stop-ramping

[MatKlucznyk]

Yes, let me see if I can remote into the client site and do some remote testing. May not be until tomorrow but I'll give it a go ASAP. Obviously, when I tried to replicate the bug to do a screen capture, I couldn't make it happen, but it does it when it wants.

Were you able to test this in your environment? I've merged the fix into the main branch.

[muzicman82]

I just tested this remotely and it still appears to do the same thing..

2023-11-14_11-44-28.mp4

Could it have something to do with how I'm controlling a mixer fader? Since I can't control a fader of a mixer directly, I'm controlling a Gain object and then have control pins linked to the channels on a mixer. I also have the mixer pins linked back to the gain, because if someone were to change the level on the mixer, the Gain doesn't update (and neither would it's feedback). If this was a problem I'm not sure why it happen only some of the time.

[BrianGrossGit]

The customer I was having the issues claims it still runs away very occasionally as well, and they are using iPads these days. I know it does not help, but confirming it is still a thing out there.

[muzicman82]

Is there a way we can debug or watch API commands and responses to the core?

[MatKlucznyk]

You can set the debug value to 3 on the core module.

The ramping function is entirely in S+. I added a mutex in this version which should wait until the press event is completed and cancel the waits. It must still be spinning up threads. To confirm you updated your main branch and tested with the updated QsysFader.usp?

[MatKlucznyk]

This is a live core with the updated QsysFader.usp. What is the VolumeStep parameter in your program? I'll match it and see if theres an issue there.

2023-11-15.08.11.06.mp4

Fader parameters: