Wave detector probes shouldn't get too quiet

[samreid]

At the moment, there is a strong effect from the wave amplitude on the wave detector probe volume. This should be reduced significantly. When the wave detector probes are all the way to the right, they are barely audible.

[samreid]

@kathy-phet requested @arouinfar and @samreid to take a quick look at this after today's design meeting.

[arouinfar]

@samreid I'm finding the volume gradient to be way too aggressive. In this example, the amplitude in the detector is nearly at the max, but I can barely hear the sound with my MacBook speakers at max volume, and the common UI sounds are much louder by comparison.

[arouinfar]

While I think #483 will help address this somewhat, I still think the volume gradient should be tuned down a bit.

[arouinfar]

This should be addressed before interviews, so marking as high priority.

[samreid]

I incorrectly hypothesized this would be an easy problem to solve. The problem is that we do not have an analytical expression for the amplitude envelope--the entire model is driven by a "bottom up" rather than "top down" approach, and hence there is no way to distinguish between a value halfway up an amplitude = 2.0 curve vs a value at the top of an amplitude = 1.0 curve. The different approaches I tried to boost the volume far from the source also disturbed the volume envelope close to the source. Can we brainstorm ways to proceed?

[samreid]

Today @kathy-phet asked to be co-assigned. Any ideas how to proceed?

[kathy-phet]

There are 2 knobs:

• boost the volume across the board
• change the volume response curve so that it stays somewhat louder at lower levels of amplitude.

I would try a bit of both ... here is a current and new hypothetical volume curve.

[samreid]

We were careful to fine-tune the "quiet" parts of the oscillation envelope, and I think that would be disturbed by the reworked curve above. I'll give it a try, but I think it would change the overall sound envelope shape, not just the volume.

[kathy-phet]

Can you make a separate dev version that just controls the volume of that one node - and boosts the volume of everything there by a factor of 3?

[emily-phet]

@Ashton-Morris @jbphet Any suggestions?

[samreid]

I'll add a query parameter ?waveMeterNodeVolume=3

[samreid]

Committed and published here: https://phet-dev.colorado.edu/html/waves-intro/1.1.0-dev.16/phet/waves-intro_en_phet.html?waveMeterNodeVolume=3

I'll need feedback before I can proceed on this issue.

[jbphet]

@Ashton-Morris @jbphet Any suggestions?

One thing to try might be a sigmoid function. We were having some issues with mapping certain aspects of the Friction sim's behavior to volume, and this function was well received as the volume control. You might need to invert it (i.e. subtract the value from 1) for your purposes, but it's something to consider. Please see https://github.com/phetsims/friction/issues/159#issuecomment-450767159 and the associated commits for details.

[samreid]

I'm having difficulty seeing how changing the response function will correct this problem. Elaborating on the problem identified in https://github.com/phetsims/wave-interference/issues/482#issuecomment-595278265 in this context:

Let's say at the wave source, the wave oscillates between +1 and -1. And out toward the right, the wave oscillates between 0.2 and -0.2. If we boost it (with a sigmoid or any other "reworked" function) so that a wave value of +1 maps to outputLevel 1 and wave value 0.2 maps to outputLevel 0.9 (for example), this will wreck the quiet parts of the +1/-1 oscillation.

One way to proceed would be to "detect" the peaks and troughs, but that sounds messy, bug-prone and would introduce a latency (have to wait for a cycle before we can approximate).

Brainstorming another option: what if we multiply the output level by a scale factor that depends on the distance from the oscillation source to compensate for this? Self-assigning for investigation.

[kathy-phet]

Brainstorming another option: what if we multiply the output level by a scale factor that depends on the distance from the oscillation source to compensate for this? Self-assigning for investigation.

Sam - this doesn't help because you can have a low amplitude by turning down "amplitude" so you actually have the same softness issue at the source, not just at the distance.

[samreid]

You are right, thanks for stopping me before I got too far on this path. We could backtrack and compute "what was the amplitude at the origin at a time corresponding to a distance x=v*t away from the origin". That is messy and sounds error prone, but I think we had to do something like that for another feature.

[kathy-phet]

I think the waveMeterNodeVolume x 3 goes a long way to making this better - @arouinfar can you check out that version. I would maybe try x4.

[kathy-phet]

I like "x 4" on the wave meter sound, but then recommend overall reduction of sound across the board of about 50%, so that the background sounds are quieter when played at 50% on my speaker settings.

[samreid]

The overall normalization is set to match up with other simulations, please see #483

[kathy-phet]

Hmmm.... I see. I think that this new default level is sounding louder than what I thought the objective was of "muted background sounds" for a 50% volume set on my laptop.

[kathy-phet]

Can you post a version that has a query parameter for this value?

[samreid]

@jbphet is there a sound volume query parameter? I see ?audioVolume but it is listed as deprecated.

[arouinfar]

Hmmm.... I see. I think that this new default level is sounding louder than what I thought the objective was of "muted background sounds" for a 50% volume set on my laptop.

@kathy-phet please watch the video I posted in #483. On the interview test device at full volume, I could barely hear any of the sounds in the sim before @samreid boosted the overall volume (relative volumes should have remained the same, though).

@samreid I also like waveMeterNodeVolume=4. It's a bit loud near the source (which is reasonable), but I can still hear the sound when it gets fainter on the other side of the lattice. One thing I'm noticing is that the darker probe generally seems softer/lower volume than the lighter probe. Am I imagining things, or do you hear it too?

[jbphet]

@jbphet is there a sound volume query parameter? I see ?audioVolume but it is listed as deprecated.

No, there is not. The audioVolume parameter was used in the past to prevent a lot of sound generation during fuzz testing, that is now covered by sound=muted. @kathy-phet's comment about "muted background sounds" is a bit of a concern for me, since I think we should have consistent levels for common components in all sims. If these are too loud, that should be addressed separately as a global issue.

For sim-specific sounds, you could always create a query parameter with an output level or a scale factor that could be passed in to the sounds as their initialOutputLevel values during construction.

[samreid]

@jbphet if @kathy-phet still wants me to publish a version where all sounds are 50%, how would you recommend to do that?

[jbphet]

If you want to do this for all sounds, and not just sim-specific sounds, you can use soundManager.masterOutputLevel = 0.5 at some point after initialization. Does that answer the need?

[emily-phet]

I think there are two issues potentially conflated in this thread. I think they are likely best handled as two independent issues (as @jbphet is indicating a few comments up).

1) Issue 1: Controlling volume mapping for the wave detector probes. I interpreted @samreid initial issues as indicating a need for better volume mapping, and in doing this found challenges given the underlying sim model. I think this is the target challenge for this specific issue (#482). From my understanding, this issue is only a problem if it inhibits the ability to balance sound (see next bullet).

2) Issue 2: Balancing sounds across the sim. This is tuning the sounds (and for sonifications, the amplifying or reducing the sound across the mapping) to align with a) concurrent playing sounds in the sim, b) all other sounds in the sim, and c) sounds across sims. This is a distinct step in the sound design process, and should be led by @Ashton-Morris with input from the team regarding individual sound salience, etc. There are now multiple sound-balancing related issues open. I'll send a message over Slack regarding this.

[samreid]

Would it work to proceed with the waveMeterNodeVolume=4 which is currently in master, then address the overall balancing in #473? If so, can this issue be closed?

[emily-phet]

I investigated the range of sound in current sim on phettest across wave extremes, and the current volume range seems fine to me.

• At the lowest frequency and amplitude (with the probe right under the faucet) I couldn't hear the sound, but increasing amplitude slightly (maybe 5-10% on the slider) and I could hear it.
• At the highest frequency / amplitude (with probe right under faucet) the probe was loud, but not uncomfortably loud.

I think this range is a reasonable indicator of the extremes. There will be times when the meter probe is not audible, but those times are when the wave amplitude is very, very small. It may be an unavoidable outcome of using a volume mapping that we won't be able to have a wave meter tool sound that simultaneously has: 1) audible at all times, and 2) does not get uncomfortably loud at large amplitude, and 3) has perceivable changes in volume across the majority central span of the sliders.

Let's proceed with what we have now, and re-open if we find that we cannot proceed with scenarios where the sound is inaudible.