in proportion sound should play when skipping over the "in proportion" range

[zepumph]

@jbphet mentioned this in the design meetings as well as over in #144 (comment). If you quickly move from the top of the screen to the bottom, it is likely that an in Proportion value is never actually set to the Property, so we should handle the case where the values "straddle" the in proportion value (on either side of it).

[zepumph]

I got this working as the design spec was thought through for mouse input, and I committed it so that people could experiment, but it is really weird for keyboard navigation. In that input modality, there are many cases where you are moving the value directly to a new number, and not thinking about dragging through the range to that number. The easiest example is when pressing home/end. Should toggling those play an in proportion sound each time? I think not.

My opinion would be to revert this change, and not support this case at all. If a user moves too fast that a Property value is never set directly in the proportion success range, then no sound should be played. This will help keep the sim simpler with code and user interaction.

@BLFiedler and @jbphet please play around with master using mouse and keyboard, and let me know what I should do.

[zepumph]

I am going to mark this as high priority because we are trying to solidify sound design this week.

[jbphet]

I tried this out on master, and having it make the peak sound every time to me seems correct to me. @zepumph said,

If a user moves too fast that a Property value is never set directly in the proportion success range, then no sound should be played.

In my opinion, since the user has no knowledge of Property values and such, the speed at which the hands move shouldn't determine whether this sound is played. Crossing the sound barrier always creates a sonic boom, regardless of how fast you do it, and this seems like an analogous case. Similar cases come to mind for me, like driving over a speed bump, or running through a sprinkler. Regardless of how fast you do it, you'll always experience some amount of the effect.

For the specific case of the keyboard nav changing a hand's position from the bottom to the top (or vice versa), it didn't bother me that the sound was played, but if it is troublesome to others we could consider it to be a special "teleportation" case where the code isn't interpreting the hand as traversing the space. I don't have a strong opinion either way on this, but I suspect it would be simpler to just leave it as is.

[brettfiedler]

A little uncertain on the keyboard interaction. By skipping by you do still hear a (very truncated) success sound, which to me may indicate you've "passed" the zone and need to backtrack to find it. But it also may mistakenly sound as though you've found the proportion when you haven't quite. Gut tells me to leave the sound there with the same behavior as the mouse, but might be worth a quick chime in from @emily-phet or @terracoda re keyboard interaction.

I do really like the interaction with the mouse though and agree with John's opinion as detailed above.

[zepumph]

In sound design meeting today, we agreed that for mouse/touch this makes sense as implemented above, and we would like to keep it. We also agreed that it is buggy for keyboard, where the interaction is more of "warp" right to the value it is set at. I will work at making this behavior happen, though at this time I don't know how hard it will be.

[zepumph]

I was able to add an option to the inProportionSoundGenerator to toggle this feature on and off. It is only on when a hand is being dragged with mouse/touch. @BLFiedler please review. Anything else for this issue?

[brettfiedler]

Tested - looks great! Closing.

[zepumph]

Reopening, right now there is a bug where this behavior occurs even when one or more values are in the "hollywood zone" of no success at the bottom of the position range.

[zepumph]

I think that will fix this. Closing