Simulation thinks there is a locked ratio in Discover section of R&P

[DevonQui]

Test device
MacBook Pro
Operating System
Big Sur 11.0.1
Browser
Safari
Problem description
This is for https://phet-dev.colorado.edu/html/ratio-and-proportion/1.0.0-dev.77/phet/ratio-and-proportion_all_phet.html
In the Discover tab of the simulation, I was able to reproduce the "locked ratio" sounds of the Create tab. I'm not entirely sure if this was intentional but my impression was that you could only reproduce them if the hands are moving together in their locked ratio which is not supposed to be possible in the Discover tab. In the video, you'll notice that in both sections, the "angelic voice" sounds are made for both. This isn't a particularly egregious bug but I thought it might be important to note in case it's related to any other underlying issues.

Steps to reproduce

1. Open the simulation
2. Click on the Discover tab
3. Click on Challenge 1
4. Allow keyboard accessibility by clicking the Tab button
5. Click Tab twice until the entire scene is highlighted
6. Move both hands to position 1 (both at the same height)
7. Using both WASD and arrow keys, move both hands between 0 and 1 simultaneously
8. Note the sounds that are produced are same as those made when the ratio is locked in the Create section
   Visuals
   Here is a link to the visual
   https://drive.google.com/file/d/1JUlw1lMP6lAtX19w7g1rIn4UWP6HPHaI/view?usp=sharing

Troubleshooting information:
!!!!! DO NOT EDIT !!!!!
Name: ‪Ratio and Proportion‬
URL: https://phet-dev.colorado.edu/html/ratio-and-proportion/1.0.0-dev.77/phet/ratio-and-proportion_all_phet.html
Version: 1.0.0-dev.77 2020-12-08 00:32:10 UTC
Features missing: touch
Flags: pixelRatioScaling
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.1 Safari/605.1.15
Language: en-us
Window: 1440x792
Pixel Ratio: 2/1
WebGL: WebGL 1.0
GLSL: WebGL GLSL ES 1.0 (1.0)
Vendor: WebKit (WebKit WebGL)
Vertex: attribs: 16 varying: 15 uniform: 1024
Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 32)
Max viewport: 8192x8192
OES_texture_float: true
Dependencies JSON: {}

[zepumph]

Nice find! There could be a little more memory when determining if the in-proportion sound should play currently it will turn on if criteria is met in a single instance, with no care for trend:

    Property.multilink( [
      model.ratio.changeInAntecedentProperty,
      model.ratio.changeInConsequentProperty,
      model.ratioFitnessProperty
    ], () => {
      if ( model.ratio.movingInDirection() && // only when moving
           !model.valuesTooSmallForInProportion() && // no moving in proportion success if too small
           model.inProportion() ) { // must be fit enough to play the moving in proportion success
        this.movingInProportionSoundClip.setOutputLevel( 1, .1 );
        !this.movingInProportionSoundClip.isPlaying && this.movingInProportionSoundClip.play();
      }
      else {
        this.movingInProportionSoundClip.setOutputLevel( 0, .2 );
      }
    } );

I can work at smoothing this out by running it on step.

[zepumph]

Note #297 as a potential sibling to this issue.

[zepumph]

The above fixes the moving in proportion sound, in kinda a hard coded way, but I felt like this was the best way to go since #326 didn't really end up fixing this. @DevonQui can you confirm fixed on master please.

[DevonQui]

@zepumph I tested this in master along with the sim link provided above and it's much improved but I was still able to produce the sound. It only lasts for a split second as compared to before but it's still there. It's not a particularly egregious bug so let me know your thoughts on closing. Here's a link to the video I took during testing.

https://drive.google.com/file/d/1Nob4-KIvok2g7giZ2l5sciC58vWXEwu4/view?usp=sharing

[KatieWoe]

I did see this, but it took some quick button presses to try and keep them in ratio as things were moving. At that point I think that the user should hear the sound anyway since they did something that kept the hands in ratio. If it becomes too hard to make the sound then moving the hands at the same time with multitouch and keeping them in ratio may be too difficult.
I'll keep an eye out though.

[zepumph]

@BLFiedler, @terracoda, and I discussed this during design meeting today.

To reiterate from This is happening because moving both hands with the keyboard just a single time each is enough to put the model into the movingInDirection state. I tried to make this more robust in #326 but sorta failed. As a result when the threshold lowers, it

As it pertains to the moving in proportion sound, @BLFiedler thought that it wasn't particularly egregious. Basically at the best case, you are going to cue that something special here is happening, and try to investigate moving both hands further. At worst, this only will happen at lower values.

We did though feel like the in-proportion ding was jarring when moving "up" in the above video https://drive.google.com/file/d/1Nob4-KIvok2g7giZ2l5sciC58vWXEwu4/view?usp=sharing, from .5/.1 to .1/1.5. We lowered the threshold so that this doesn't occur for this particular case (with large keyboard steps), though it can still happen when looking for it in shift-key step cases.

We didn't think that this problem was large enough to try to carry it to other cases. Over to @BLFiedler to make sure the threshold change isn't a regression for touch input.

[brettfiedler]

It's certainly still a tricky task, but nothing buggy that I can see. Closing.

[zepumph]

Reopening. If we do and up fixing the moving in direction algorithm over in #360, 86bccf2 should be reverted since it was more of a work around.

[zepumph]

Reverted above. I will cherry pick over in #360.