>> Yes, but that scaledVol value is already set to change cyclicly (is that a word?) in FMSound organ1 in order to modulate the base sine wave and give it some timbre. If we attempt to use that same value to control the overall loudness, we will lose the timbre. In fact we would need to multiply the timbral volume envelope with the loudness one, but this is not trivial because the first one uses a loop.
> 
> I *think* that the FMSound>>#primitiveMixFMSound code handles this; at least it looks like it pays attention to the waveTable etc. I've just taken a quick look and the code that changes the scaleVol if the scaledVolIncr value is non-0 is there in the prim too, so there hasn't been a major regression in  the code. Probably.

That's what I am talking about. Because there is only one scaledVol 
instance, its evolution in time can be (and actually *is*) described by 
a *single* envelope.

Now see the code in FMSound>>#organ1
There, that envelope is defined in

snd addEnvelope: (VolumeEnvelope points: p loopStart: 2 loopEnd: 4).

So that is what drives the time evolution of scaledVol. It is a short 
envelope constantly looping over break points 2 to 4.

If you now want to control the overall loudness of the sound, let's say 
for a crescendo, you have to surimpose to this scaledVol evolution a 
gradual increase of its max value - this cannot anymore be defined by a 
looping envelope.

Stef