Sound changes from Extended

[jamespetts]

I wonder whether some sound changes that I have recently made to Extended (some superseding a more basic version that I implemented as long ago as 2009) might be of use to Standard? They are the sort of feature that would potentially be suitable for Standard.
In summary, there are two changes:
(1) cooldown timers; and
(2) zoom level dependent volume issues.
The cooldown timers prevent a sound of one type from being played too soon after a sound of the same type has recently been played. This prevents annoying repetitive sounds in well developed towns.
The zoom dependant volume levels just reduces the volume as one zooms out so that, at higher zoom levels, one may get more sounds, but they are all quieter.
Players on the Stephenson-Seimens server have reported that this greatly improves the sound experience.
The Git commits for this are here and here.

[prissi]

The zoom factor is too generic, since it depends on screen size and pak size. It should depend on the number of visible tiles. pak256 will have a quarter of sound (just by tile size regulation objects) at the same zoom level than pak128.

In that regard, the volume should rather depend on the distance on the screen, and not (as currently) on the distance in tiles.

A cooloff time is built in in GDI, since it can only play one sound at the time and ignore all coming up sounds. But I will look into it.

EDIT: The cooloff timer does not apply for money messages, although I find them the most annoying in big cities. It seems a finer setting of noises might be needed. (For instance almost no factory or environmental noise settings exist, although mostly because no noises exist for them in most pak sets.)

Rather a todo topic, I fear. Thank you for the patch.

[Mariculous]

Sadly Linux users don't have a built in cooldown, so the first ting they do in standard currently is disabling sound.

Nevertheless, I guess that "built in cooldown" is too short in time as it won't prevent the same sound from starting again immediately when it stopped.
I must admit since I was told the sound was improved I gave it a try and since then have sounds enabled.

The cooloff timer does not apply for money messages, although I find them the most annoying in big cities.

Now I know what that sound around my airport I could not relate to was. However, the pak128.britain-ex sound itself is by far less annoying than the pak128 standard sound. Same goes for destruct tool sound and "can not do this" sound.

However, now that I know it was the money message sound, this could really need a cooldown.

[Leartin]

A cooloff time is built in in GDI, since it can only play one sound at the time and ignore all coming up sounds.

Sounds can get interrupted though, the newer sound is prioritized.
Which is also why sounds for factories are not that nice and imho not worth it right now, they are constantly interupted by vehicles and ka-ching.

[jamespetts]

Thank you all for your feedback. I should note that the automatically compiled binaries of Extended use SDL2, which allows multiple sounds to play at once. The interrupting of sounds with GDI makes them even more annoying. With SDL2, industry sounds work quite nicely - there are a few in Pak128.Britain-Ex.

The trick for sound engineering, incidentally, is to find the right sounds and edit them well. Sounds should:

(1) fade in quickly;
(2) fade out slowly;
(3) not be too long;
(4) not be too jarring, but be gentle, background sounds that do not suggest urgency;
(5) be normalised; and
(6) be of good audio quality without background noise.

As to the cooldown period for the money sound, I do not find this a problem myself; what are the views of other Extended players on this issue?

[prissi]

I looked at the code. The original routine had already a zoom factor dependent scaling factor.

Code Select Expand


bool karte_t::play_sound_area_clipped(koord const k, uint16 const idx) const
{
if(is_sound  &&  zeiger) {
const int dist = koord_distance( k, zeiger->get_pos() );

if(dist < 100) {
int xw = (2*display_get_width())/get_tile_raster_width();
int yw = (4*display_get_height())/get_tile_raster_width();

uint8 const volume = (uint8)(255U * (xw + yw) / (xw + yw + 64 * dist));
if (volume > 8) {
sound_play(idx, volume);
}
}
return dist < 25;
}
return false;
}
get_tile_raster_width(); is the actual size of a tile with the current zoom factor. The other thing is the size of the display. Hence with very large displays, the reduction is not as fast as one may have wished for. Instead the sounds getting louder the bigger the display. Also getting louder when zoomed out.

They were are fundamentally wrong, since they were essentiall a 1/distance law, instead 1/distance^2. Far away sound were getting way too loud, see the long tails in the graph. That gets even worse when zooming out (dotted lines) and with 4k displays.

Hence I propose the following formula (magenta line)

Code Select Expand

uint8 const volume = (uint8)((255U * sound_distance_scaling) / (sound_distance_scaling + dist*dist));

scaling is a factor which determines how fast the sound will fade. A factor of 10 give something similar to now, although close sounds will be louder. But that factor could be user provided.

[jamespetts]

Thank you for that. I have adapted this for the master branch of Extended. The original version did not seem to reduce the sound sufficiently on zooming, so I have modified the algorithm thus:

Code Select Expand


uint32 dist = shortest_distance(k, viewport->get_world_position());
bool play = false;

if(dist < 96)
{
dist = max(dist - 8, 0);

// Higher numbers are more zoomed out, so 3 is normal zoom,
// 0 is maximally zoomed in and 9 is maximally zoomed out
uint32 zoom_distance = get_zoom_factor() + 1;
dist += (zoom_distance * 2);

const uint8 sound_distance_scaling = 16; // TODO: Set this by simuconf.tab
const uint8 volume = (uint8)((255U * sound_distance_scaling) / (sound_distance_scaling + dist * dist));

if (volume)
{
sound_play(idx, volume);
play = true;
}
}


This seems to produce more pleasing results than my original algorithm. I have no yet fully experimented with different values for sound_distance_scaling.

[prissi]

The max(dist-8,0) is nod needed I would say, since the quadratic decreases much slower too. I am currently renovation the sound system in standard, to allow also a different volume for each type of sound, to mute for instance only tool and money sounds.

EDIT: Incorporated in r8887, including different volumes for different sounds (but no cooldown timer)

[Dwachs]

There is a strange if clause in simsound.cc line 76:

   return (  env_t::global_mute_sound  ||  (SFX_CASH == NO_SOUND)*255  );

this 255 does not look right.

[prissi]

Indeed, thanks for spotting it.

But I do not like to assume that every pakset must have the ching sound, or no sound will play. I thing the second part should entirely go away.