New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GVARS redesign #3185

bsongis opened this Issue Dec 30, 2015 · 8 comments


None yet
7 participants

bsongis commented Dec 30, 2015

As stated by many issues. GVars would benefit from 3 more parameters:

  • Add an unit. It would solve our problem with GVars used for channels. Some like to use 512us, other 100%, other 1024(raw)
  • Add a prec. It would take care of #1361 and #905
  • Add a min/max which would be used by the AdjustGVar function
  • AdjustGVar (+/-X) instead of AdjustGVar(+/-1), people wait for this function since long, cf #1713

GVars are needed in some more menus:

  • Audio Volume #2248
  • Slow / Delay

There is also some existing bugs related to gvars when using FUNC_ADJUST_GVAR:

  • The increment/decrement is missing a limit check. The value of gvar can thus be incremented or decremented beyond the normal range. (#2917)
  • Another AdjustGVar issue #3103

This comment has been minimized.


fraternl commented Jan 3, 2016

I haven't been following developments in the last 2 months and noticed these changes in gvar.
From what I gather I can soon change a gvar using a stick as a direct source and let it change a gvar within my desired range.
This means that one doesn't have to use a helper channel with a dedicated curve to achieve this (unless I want even more control).
Am I correct in this?

I wanted to test this, but I don't have a development environment and am using nightlies.
I will test it when it lands there....


This comment has been minimized.


kilrah commented Jan 3, 2016

No, the idea would have been to use the new limits as a clamp, not scaled to the input.

Reason is that if we scaled and that's not what the user wants it's hard to "undo" the scaling, while the current way of using a channel makes the opposite easy.


This comment has been minimized.


bsongis commented Jan 3, 2016


bsongis added a commit that referenced this issue Jan 13, 2016

[Horus] GUI continued - #3159
[GVars] Refactoring continued - #3185

This comment has been minimized.


bsongis commented Jan 13, 2016

Some progress on this in my last commit. GVars names are now reduced to 3 chars. Curves as well. Names for GVars and Curves will be used everywhere in the firmware now.

Tests needed please!

bsongis added a commit that referenced this issue Jan 14, 2016

[Horus] GUI continued - #3159
[GVars] Refactoring continued - #3185

This comment has been minimized.

lshems commented Feb 1, 2016

any suggestions for tests?
Able to do some.


This comment has been minimized.

hmichl commented Feb 12, 2016

I really like this thread and support the idea of having GVARs at additional places. One request I would like to add is having also the possibility to have a GVAR instead of a value at the weight of trainer-functions. I want to be able to change this weight dependend on the position of the stick of the master-transmitter (for example the more I move my stick to a maximum position the less weight the student has). I already implmemented this functionality with a lot of mixers using TR1 to TR4, but having it where it belongs to (in my opinion :-) would be great!

In addition to this, it would generally be cool to have the choice of either GVARs or the value of a channel. I often use channels and functions to generate values, but then have to assign exactly these values to a GVAR. Would be cool to skip this one step.


This comment has been minimized.


RCdiy commented Feb 6, 2018

I've defined LS1-5 like this. Ignore L1.
GV1 changes with stick THR
GV2 is 50%
GV3 is 50
When comparing THR against GV2 and GV3 should the behaviour not be different?
When THR is equal to 5 why is it equal to both 50% and 50?
I thought THR had unit % so 5 should not be equal to 50%.

Here is the OTX file. Rename and remove .txt to use it.


This comment has been minimized.


kilrah commented Feb 7, 2018

Ah I believe the % is only for display, you need to set the "precision" for actual scaling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment