I'm currently working on porting the gain caps from rawaccel into YeetMouse (Classic one for now)

[anengineer1]

Greetings,

I've been digging into rawaccel and I wanted to port that functionality into YeetMouse; so far the curve classic seems to be a success (for now, only the GUI part, there still work ahead):

Before continuing I want to discuss some stuff:

1. The name of box, I don't know if the name "Use Smothing" is still correct as we are adding a smooth cap... you think "Use Smooth Capping" might be a good name?
2. I'm using "Midpoint" for the "Limit" which is the same name we decided for Natural (feel free to disagree if you want another name or you prefer another variable).
3. Functionality-wise, if "Use Smoothing" is unchecked, "Midpoint" disappears. Do you agree with such behavior?

Thank you a lot.

(Special thanks to MxCraven and Macii as they were patient enough to let me use their windows machine to compare the curve with the rawaccel one and @deavid for proposing the name "Use Smooth Capping")

EDIT: I saw a big PR for the synchronous curve, perhaps it is better to wait until it is merged into master before I proceed?

[AndyFilter]

Hey, It's great to see work like this being done on this project!

I'll start by saying that I've never heard about gain cap before, but I've read about it and it seems like a reasonable idea.

About the questions You've asked:

1. The name of box, I don't know if the name "Use Smothing" is still correct as we are adding a smooth cap... you think "Use Smooth Capping" might be a good name?

I think "Use Smooth Capping" might be more suitable, but feel free to also just use "Gain Cap". I considered recently to update the names of "Use smoothing" to simply "Gain" to cut down on the confusion for people switching from RawAccel.

2. I'm using "Midpoint" for the "Limit" which is the same name we decided for Natural (feel free to disagree if you want another name or you prefer another

Cool, it's the closest parameter out there I think. No objections here.

3. Functionality-wise, if "Use Smoothing" is unchecked, "Midpoint" disappears. Do you agree with such behaviour?

Yea, that sounds reasonable. It would match the behaviour of the anisotropy switch that when turned on shows a Sensitivity Y slider. So to make sure I understand correctly; if "Use Smooth Capping" is ON, and the "Limit" is set to 0, the behaviour is equal to just "Use smoothing" (or "gain")?
Also, I think that the slider (for the "Limit") could be below the checkbox (that shows the slider) to make sure You can turn it ON and OFF without moving the mouse. It would also suggest that the "Limit" is directly connected to the smoothing.

4. I saw a big PR for the synchronous curve, perhaps it is better to wait until it is merged into master before I proceed?

I just want to make sure the feature/synchronous branch works fine on Nix, as soon as I get a green light on that, the changes will be merged. I think You can easily develop the code now and simply rebase the changes once You're ready to open a pull request as the synchronous should be merged by then.

I also have a question - how does the gain caps work? Like does it just switch the equations used for the curve entirely (to account for the new dynamic gain), or does it have some kind of LUT to precalculate sums?

Overall, the change looks good, thanks for the work!

[AndyFilter]

Quick note: I just checked the RawAccel implementation of this, and it turns out they give the ability to select the "cap type" (input, output, both). I don't think this is necessary here (as they all boil down to the same thing (I think)), but I'd be good to maybe instead of "Limit" call it "Out. Limit" (or "Output Limit").

[anengineer1]

Greetings, sorry for the delay in the answer:

but I'd be good to maybe instead of "Limit" call it "Out. Limit" (or "Output Limit").

Ok, we will call it "Output Limit".

I think "Use Smooth Capping" might be more suitable, but feel free to also just use "Gain Cap"

I'll try "Use Smooth Capping"... even thought RawAccel says "Gain", IMHO it is not descriptive enough for the average user (perhaps I'm wrong... feel free to say the opposite)

So to make sure I understand correctly; if "Use Smooth Capping" is ON, and the "Limit" is set to 0, the behaviour is equal to just "Use smoothing" (or "gain")?

I'm not sure I'm understanding the question... so I'll reply with a screenshot and hope that answers it:

Also, I think that the slider (for the "Limit") could be below the checkbox (that shows the slider) to make sure You can turn it ON and OFF without moving the mouse. It would also suggest that the "Limit" is directly connected to the smoothing.

Sure, I agree, no problem.

I also have a question - how does the gain caps work? Like does it just switch the equations used for the curve entirely (to account for the new dynamic gain), or does it have some kind of LUT to precalculate sums?

It is basically 2 functions glued together, the first part is the untouched original equation while the other part was made using the derivative in order to be sure the first derivative is continuum on both x sides of the transition point so you can have the smoothness you are seeing. There's a part where it calculates the transition point. They have this document where they explain it a bit (my English is terrible, sorry for that):

https://docs.google.com/document/d/1FCpkqRxUaCP7J258SupbxNxvdPfljb16AKMs56yDucA/edit

I'm still working in cleaning up the equations code.

I hope I answered everything.

Thank you for your time!

[anengineer1]

Greetings, I've passed the equations into the driver itself and the maximum I can accomplish is a tolerance of 0.001 with the floating point curve which I think it should be enough:

result 3.282298
Eval function: 3.282499
result 3.285038
Eval function: 3.285238
result 3.287771
Eval function: 3.287972
result 3.290500
Eval function: 3.290701
result 3.293223
Eval function: 3.293423
result 3.295941
Eval function: 3.296141
result 3.298653
Eval function: 3.298853
result 3.301360
Eval function: 3.301559
result 3.304061
Eval function: 3.304261

Do you agree?

[anengineer1]

But I have to note that the fixed point code I found in the fork did not work for me properly, and instead I used this:

Yes, basically cause the code there is behind of what I have on the drive, that's why I said "Knowing that you check my fork from time to time, I'll try to push stuff before asking".

I'm happy you digged into it but I want to ask, do you prefer the code you wrote or the one I corrected (basically what you read but with a correction in the last equation)?

[anengineer1]

Sorry for the spam in the comments, I just placed the constants into the section you mentioned before as only doing that it has the precision you talked about before. Good stuff

This time I learned my lesson and pushed the code so this time you don't have to do the same work twice for no real reason... now there is nothing in my local drive that's not there.

don't be very thorough in reviewing the code yet... I still have work to do like nonsensical comments, a bit more testing, etc...

[AndyFilter]

Looking at the code from the fork in the current state (322f34d), there still seems to be some issue with the driver code, and I think it's not just fixed point precision. When running the same test as last time, I got this error:

x: 22.650000, fixed: 1.0105870, floating 1.4538553, L1 err: 0.443268299
x: 22.799999, fixed: 1.0368330, floating 1.4771852, L1 err: 0.440352201
x: 22.950001, fixed: 1.0627364, floating 1.5002103, L1 err: 0.437473893
x: 23.100000, fixed: 1.0883030, floating 1.5229361, L1 err: 0.434633136

which is much greater than something that fixed point precision (or the lack of) could cause.
But keep in mind that the driver code is being compared to the floating point code, and I don't know which one might be off. It's probably some tiny issue, something like "off-by-one", looking at the fact that the error is shrinking as the x value gets larger.

I'd like to keep Your code, but I also don't want You to work just on that for too long. I based my snipped of the code from earlier on the floating point code of Yours, so feel free to use it.

[anengineer1]

Yep, you are right with the values you mentioned the error is too much, I'll use your code if necessary. I'll look into it when I can as I have the rest of the day busy.

[anengineer1]

Ok, again, sorry for writting to much today. After using the constant formula you simplified, the results are now accurate with the values you used. I did the push. I tried to let it be and work on another day but it seems I just can't.