Hi Stéphane.

> From a musical perspective, there is always some reverb. Nobody plays a
> concerto in an anechoic chamber. So you can think of the default reverb
> setting as the sound of the Squeak room itself - when just playing
> sounds like, for a game, it is nicer to have one. And when we need
> Squeak to behave like an anechoic chamber, we can just turn the reverb off.

Aha! Thanks for this explanation. :-)

Best,
Marcel
Am 31.05.2021 09:36:10 schrieb Stéphane Rollandin <lecteur at zogotounga.net>:
> FMSound brass1 play
>
> And I have to tell that, both with default and without reverb, I can hear the abrupt end of the sound very clearly.
Well without reverb there is a definitely non-musical harsh noise. With
reverb on, the sound still does stop abruptly, but more musically. This
makes all the difference to me.

But I do agree that overall the FMSounds releases are not graceful :)


> IMHO it does not make a large difference, except for the fact that a pure tone should not have any reverb by definition.

A FMSound is not a pure tone. A pure tone is a sinusoid, which ends with
a clear click (a very non-musical noise).

Now anyway the reverb is used only when playing a sound, not when
processing it - here it is not part of the FMSound itself: you will not
see the reverb in the waveform or the spectrogram.

>From a musical perspective, there is always some reverb. Nobody plays a
concerto in an anechoic chamber. So you can think of the default reverb
setting as the sound of the Squeak room itself - when just playing
sounds like, for a game, it is nicer to have one. And when we need
Squeak to behave like an anechoic chamber, we can just turn the reverb off.

>
> I am not an expert in sounds at all, but couldn't it be a more elegant solution to adjust the envelopes of the problematic sounds instead and to extend their release phase?
>
> I changed #brass1 like this:
>
> | snd p env |
> snd := FMSound new modulation: 0 ratio: 1.
> p := OrderedCollection new.
> - p add: 0 at 0.0; add: 30 at 0.8; add: 90 at 1.0; add: 120 at 0.9; add: 220 at 0.7; add: 320 at 0.9; add: 360 at 0.0.
> + p add: 0 at 0.0; add: 30 at 0.8; add: 90 at 1.0; add: 120 at 0.9; add: 220 at 0.7; add: 320 at 0.9; add: 440 at 0.0.
> snd addEnvelope: (VolumeEnvelope points: p loopStart: 4 loopEnd: 6).
>
> p := OrderedCollection new.
> p add: 0 at 0.5; add: 60 at 1.0; add: 120 at 0.8; add: 220 at 0.65; add: 320 at 0.8; add: 360 at 0.0.
> env := Envelope points: p loopStart: 3 loopEnd: 5.
> env target: snd; updateSelector: #modulation:; scale: 5.0.
> snd addEnvelope: env.
>
> (snd setPitch: 220.0 dur: 1.0 loudness: 0.5) play
>
> The only difference is that I moved the last envelope point 80 ms to the right. I can't hear any "plop" now any longer.

Right, but the duration of the sound cannot be considered to be one
second anymore - it is much closer to 0.9 seconds (where it was around
0.95 before, so already too short).

See the attached pictures: SoundElementEditor1.png is the current
waveform, SoundElementEditor2.png the one you propose. See how it ends
prematurely?

I would say 390 at 0.0 for the last point is better. It still sounds good,
but does not shorten the sound as much.

For composition, it is important that a sound lasts as long as it claims
to last. Else, the phrasing articulations cannot be right - you would
hear a staccato when a legato is asked for.

So a sound release should happen after the sound nominal duration (which
is not the case at the moment)


> My proposal is to turn off reverb in the SoundPlayer by default and to adjust the most problematic FMSounds manually instead. What do you think? :-)

My counter-proposal would be to keep the default reverb and give it the
settings it has in muO :)

And then, if you want to tweak some sounds, have their nominal duration
respected. So I would vote for having releases after nominal duration,
but this means a mechanism would then be needed to differentiate the
nominal duration from the duration you get from the raw number of samples.

This mechanism exists in muO.

In fact it is rather difficult for me to give any specific piece of
advice about how music should be handled in Squeak proper, because my
own way to do this has been to implement a much vaster and deeper
framework where many different perspectives work together. Not to say it
is perfect, but it is thorough - one thing lead to another and I could
talk for hours...


Best,

Stef

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210607/3bfaf26f/attachment.html>