Questions about sound implementation in WaveInterferenceSlider.js

[pixelzoom]

Some questions, to help proceed with https://github.com/phetsims/fourier-making-waves/issues/56 and https://github.com/phetsims/sun/issues/697

WaveInterference.js adds sound support to HSlider.

For the if ( event.isFromPDOM() ) code path:

(1) Why is a different code path required when event.isFromPDOM()?

(2) Why is TOLERANCE needed in this code path, and not the mouse/touch code path?

(3) Why is there no need to verify the elapsed time between sounds, as in the mouse/touch code path?

For the mouse/touch code path:

(4) Why is it not necessary to check elapsed time before playing generalBoundaryBoopSoundPlayer?

(5) MIN_INTER_CLICK_TIME is documented as "min time between clicking sounds", and I interpret "between" to mean the gap between sounds. But it actually appears to be the min time since play was called for a clicking sound. Do I understand that correctly?

(6) MIN_INTER_CLICK_TIME is "set empirically" for the specific sound files used, correct? If I used a longer/shorter sound, then I'd need to adjust it? And if SoundClip had a getDuration method (see https://github.com/phetsims/tambo/issues/141) would that make it possible to compute this programmatically, as "duration + gap"?

[samreid]

(1) Why is a different code path required when event.isFromPDOM()?

From the keyboard, there should be a sound with every keypress. For mouse/pointer, there should only be a sound when you reach a tickmark.

(2) Why is TOLERANCE needed in this code path, and not the mouse/touch code path?

From my testing, it doesn't appear to be needed in either code path. It was described in https://github.com/phetsims/wave-interference/commit/0b9318753ece23b5f6f3892efe84247585037a6a but that doesn't seem accurate any more.

(3) Why is there no need to verify the elapsed time between sounds, as in the mouse/touch code path?

Same as the response to (1). Also, for mouse/touch you can move quickly and get too many sounds to play at the same time, so it has to be throttled.

Why is it not necessary to check elapsed time before playing generalBoundaryBoopSoundPlayer?

Because hitting the extrema is rare (compared to passing over tick marks). For example, it would be difficult for a user to hit the boundary more than 1-2 times per frame, but it could be easy to cross many tick marks in one frame.

(5) MIN_INTER_CLICK_TIME is documented as "min time between clicking sounds", and I interpret "between" to mean the gap between sounds. But it actually appears to be the min time since play was called for a clicking sound. Do I understand that correctly?

Yes, it's the delta between start times.

(6) MIN_INTER_CLICK_TIME is "set empirically" for the specific sound files used, correct?

Yes

If I used a longer/shorter sound, then I'd need to adjust it?

Yes, because longer sounds would be more prone to overlapping.

And if SoundClip had a getDuration method (see phetsims/tambo#141) would that make it possible to compute this programmatically, as "duration + gap"?

Yes. That being said, it may not require exact fine tuning. For example, if one sound is 0.3sec and the new sound is 0.2sec, then the same inter click time would probably be OK. It's just about making sure that not too many sounds play at the same time, which would increase the volume.

[pixelzoom]

Thanks for the answers!

for mouse/touch you can move quickly and get too many sounds to play at the same time, so it has to be throttled.

It sounds like you're assuming that event.isFromPDOM() equates to keyboard, which is slower than mouse/touch. That's not the case - event.isFromPDOM() is any alternative input, see SceneryEvent.js:

/**
   * Specifies whether or not the SceneryEvent came from alternative input. 
...
   */
  isFromPDOM() {

.... and I can certainly imagine an input device that has the same "too many sounds to play at the same time" problem as mouse/touch. So this solution is not future-proof.

Closing.