Game: Falling node sounds.

[sofar]

Falling nodes should make a sound. This can only be done here,
so for simplicity we just call the sound_play() here with the node
place sound. We ignore any gain value in the sound spec since a
falling node should be loud, so the 1.0 default gain makes sense
here.

[paramat]

So the sound will be the same loudness as the node's placing sound? It should be.

We ignore any gain value in the sound spec since a
falling node should be loud, so the 1.0 default gain makes sense
here.

Maybe i misunderstand but this concerns me. The sound should not be played at a fixed maximum loudness as this will be too loud depending on material and waveform amplitde / compression / limiting.
But if you mean the sound will be the placing sound, with the same loudness as the placing sound then that's ok.

[sofar]

The text is clear enough.

The default gain value is 1.0. The code omits any gain value from the sound table, and therefore plays at the default (max) gain.

Most placement sounds have lower gain values since placing a node almost always happens close to the player and should be not too loud.However, failling nodes can happen and will happen further away from the player, and a normal sound level (which varies, most are already 1.0 but metal is 0.5) is likely going to result in falling nodes not being heard falling by the player, especially at really low values.

Secondary, the sound of a node crashing into the ground should be loud. No exception.

If the sound of the place sample is too loud to begin with, it should be edited and normalized instead. Reducing the gain for all variants of a sound is akin to asking all players to increase their volume while lowering the volume of the game - double work for zero effort. It also breaks down the soundscape by creating a flat soundscape where all the samples are played at the same volumes, and this becomes dull, and minetest is already an incredible mute game to begin with.

So, that should clarify why this volume level is entirely reasonable.

[ghost]

What if a bunch of nodes drop simultaneously? Result in a cacophony?

…

On Fri, Nov 10, 2017, 1:04 AM sofar ***@***.***> wrote: The text is clear enough. The default gain value is 1.0. The code omits any gain value from the sound table, and therefore plays at the default (max) gain. Most placement sounds have lower gain values since placing a node almost always happens close to the player and should be not too loud.However, failling nodes can happen and will happen further away from the player, and a normal sound level (which varies, most are already 1.0 but metal is 0.5) is likely going to result in falling nodes not being heard falling by the player, especially at really low values. Secondary, the sound of a node crashing into the ground should be loud. No exception. If the sound of the place sample is too loud to begin with, it should be edited and normalized instead. Reducing the gain for all variants of a sound is akin to asking all players to increase their volume while lowering the volume of the game - double work for zero effort. It also breaks down the soundscape by creating a flat soundscape where all the samples are played at the same volumes, and this becomes dull, and minetest is already an incredible mute game to begin with. So, that should clarify why this volume level is entirely reasonable. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6603 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWXKYpWJLcJJtZhzA1Rh1X7dDeKvUJUbks5s0-digaJpZM4QXgOY> .

[sofar]

No, the sounds all play at exactly the same time, so it's a single "thud" even with 500+ nodes (tested). The client doesn't sweat it either, I perceived no lag even with numbers this high. The sound was also a reasonable volume, it doesn't get weird.

[paramat]

Ok i agree falling nodes should be louder than placed.

If the sound of the place sample is too loud to begin with, it should be edited and normalized instead.

This probably won't happen, it also creates extra work where the gain for other uses of the sound needs to be tuned.
Normalisation doesn't equalise perceived loudness because how 'peaky' the waveform is affects that.

Anyway, i've just seen that the large majority of our place sounds are already gain = 1.0, so while i think fall gain should have a fixed relation to place gain, in MTG it makes little difference, so i'm neutral. Good feature though.

[HybridDog]

This can only be done here

No, my mod does this since 23 May 2015: https://github.com/HybridDog/falling_extras/blob/master/init.lua

[paramat]

Will test and probably +1, the idea is good.

[sofar]

@HybridDog copying and duplicating the entire falling.lua proves exactly my point, that it has to be done right there...

[paramat]

Fun, makes a good sound and really improves the experience.
Very many nodes falling (1000s) causes a few sound messages in terminal and an odd sound but no problem.

			-- Create node and remove entity
			if core.registered_nodes[self.node.name] then
				core.add_node(np, self.node)
				if self.meta then
					local meta = core.get_meta(np)
					meta:from_table(self.meta)
				end
				local def = core.registered_nodes[self.node.name]
				if def and def.sounds and def.sounds.place and def.sounds.place.name then
					core.sound_play(def.sounds.place, {pos = np})
				end
			end

core.registered_nodes[self.node.name] is got twice, and def is assured to exist due to the first condition. How about:

			-- Create node and remove entity
			local def = core.registered_nodes[self.node.name]
			if def then
				core.add_node(np, self.node)
				if self.meta then
					local meta = core.get_meta(np)
					meta:from_table(self.meta)
				end
				if def.sounds and def.sounds.place and def.sounds.place.name then
					core.sound_play(def.sounds.place, {pos = np})
				end
			end

?
+1 once code is improved.

[ghost]

I tested it, and enjoyed it, but in my experience I was not far away when the fall impact sounds were played at 1.0 gain. In fact, I was one node away digging sand and gravel deposits.

In this case, both the digging sound and the falling sound occur, and it's frequent because I did from the bottom of these deposits to save on mouse movement.

Just wanted to share, thanks for the PR. I especially enjoyed digging the bottom of a sand tower to hear the falling sounds played sequentially. The actual material sounds themselves don't do this code justice, in my opinion, but that's another matter.

[sofar]

Removed the unneeded table lookup.

[HybridDog]

Please also set makes_footstep_sound to true, it makes a splash sound when something is falling into water.

[paramat]

'if def' not needed here. Can be fixed on merge.
Otherwise 👍

[paramat]

Please also set makes_footstep_sound to true,

-1 Problem is that then causes a long sloshing footstep sound for every water node passed through for every falling node, which is much more intensive than 1 sound on landing. Large numbers of falling nodes already cause sound overload messages in terminal.
Best left to another PR for consideration.

[sofar]

Yeah, making a footstep sound isn't the right idea. Ideally we'd play a splash sound when traversing the liquid boundary, but .. yikes.. that will take a lot of code.

Removed one unneeded def check.

[paramat]

👍

[paramat]

41bc0ef

[HybridDog]

Problem is that then causes a long sloshing footstep sound for every water node

I did it with the falling_extras mod and it sounds quite well, like bubbles under the falling object making their way around it, though I think you're right with the intensity.