(setq mysound (mult s 10))
(setq newsound (clip mysound 0.5))
that the variable “s” would have its sample values multiplied by 10, and
then the resulting sound (“mysound”) would be clipped (hard limited) to
0.5
However, that does not occur.
What seems to happen is that the sound “s” is clipped to 0.5, and then
the result is multiplied by 10.
The same thing happens with:
(clip (scale 10 s) 0.5)
Why is this?
How do I clip “mysound” ?
I’m using Audacity 1.3.7 on Ubuntu 8.04
I would design it like that. Much less possibility of damage to reduce level first, then increase. Given that peaking at zero seems to be the holey grail of audio production, you have no choice. Any tool that increases the level first will fail as a product.
Did you try the Leveler? That tools basically performs more and more clipping and hard compression as you increase the value. Of course, if you’re just after getting the math to work and to heck with the sound, then this is a problem, yes.
seanybob was wanting to modulate a high frequency tone with a given “square wave” that wasn’t very square. In the code that I proposed in this post http://audacityteam.org/forum/viewtopic.php?f=28&t=9785#p40422 I have made the low frequency square wave more square by amplifying and hard clipping it.
The logical method would be:
(“clip the signal” (“amplify the signal”))
Using the usual convention of processing the innermost brackets first, it would be expected that amplifying the signal by say a factor of 10, then clipping it to a peak of 0.5 would do the job quite nicely. The code would be:
(clip (scale 10 s) 0.5)
However this does not work - it produces exactly the same result as:
(scale 10 (clip s 0.5))
which is, to clip the signal at a peak level of 0.5, then amplify it by a factor of 10.
If the conventions of the order in which nested parentheses are performed are ignored in this simple example, then it clearly has enormous implications when it comes to writing any Nyquist scripts.
I was hoping that someone could explain “why” this apparently illogical behaviour occurs, and the correct way to order sequences of processing functions.
BTW, my workaround for the code in that topic was to clip the audio to 0.01 and then amplify it by a factor of 50. A satisfactory workaround for this simple example, but it does not address the question of why Nyquist will sometimes perform functions in the expected order, and sometime not.