search

MatKlucznyk / Qsys

Qsys library for S#P and SIMPL
MIT License
53 stars 18 forks source link

Fader Volume Doesn't Stop Ramping #36

Open muzicman82 opened 10 months ago

muzicman82 commented 10 months ago

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 commented 10 months ago

Any chance this is on a tst-902?

muzicman82 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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

MatKlucznyk commented 10 months ago

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 commented 10 months ago

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

https://github.com/MatKlucznyk/Qsys/assets/9997806/4e349b97-f2ca-4271-8d9e-eb7a6dbf785e

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.

image

BrianGrossGit commented 10 months ago

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 commented 10 months ago

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

MatKlucznyk commented 10 months ago

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 commented 10 months ago

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.

https://github.com/MatKlucznyk/Qsys/assets/9019861/92f13a93-7de2-4259-8ae3-dabe429b8064

Fader parameters: image