## [Audacity-nyquist] RE: Audacity-nyquist digest, Vol 1 #65 - 1 msg

 [Audacity-nyquist] RE: Audacity-nyquist digest, Vol 1 #65 - 1 msg From: Roger B. Dannenberg - 2005-08-08 17:46:26 ```> I am using the ramp function as shown in the code below. When I=20 > run it on test data (e.g., a constant signal of amplitude > 0.5) it glitches in the last few samples of the selection=20 > that I apply it to. It smoothly ramps to the final volume=20 > as it should, then suddenly jumps to fairly random value.=20 The RAMP function is computed at the default control rate. When you = multiply by a higher sample rate signal, e.g. your audio selection, the ramp is interpolated. To interpolate, you look ahead one sample to see where the signal is going and linearly interpolate to that point. This works fine until you get to the end of the ramp. To look ahead at the end of the = ramp, you must look beyond the last sample. By definition, when a Nyquist = signal terminates, i.e. reaches the last sample that is specified by some primitive, the signal goes to zero. You can read as many additional = samples as you want, and they will all be zero. So when you interpolate the last sample period of a ramp, you will look ahead and find a zero, and the interpolated samples will linearly interpolate from 1 to 0. The default control rate is 2205, so you'd expect to see a return to zero over 20 samples if your selected signal sample rate is 44100. To avoid some of the problems caused by interpolation, RAMP is extended = by one sample. While most Nyquist primitives have a default duration of 1 second, RAMP's default duration is 1 second + 1 sample, so if you write, say, (MULT (OSC C4) (RAMP)), you will get a 1 second signal (due to the duration of OSC), and you will not see the final fall from 1 to 0, which would occur between samples 2205 and 2206 (beyond 1s) of the RAMP. Unfortunately, there seems to be some subtle interaction with the way Audacity defines the Nyquist environment and how Audacity interprets the result of a signal expression, and I assume this is causing the problem. = One simple fix may be to change the RAMP sample rate, e.g. (mult s (control-rate-abs (snd-srate s) (ramp))) Or, since RAMP extends its duration by one sample by default, it's = probably better to use PWL: (mult s (control-rate-abs (snd-srate s) (pwl 1 1))) By computing the ramp at the same rate as the audio signal, there will = be no interpolation and Nyquist will not look beyond the ramp to find any = zeros. Having introduced the idea of computing control functions at the audio sample rate, I should add that this is almost NEVER necessary when generating signals, because most audio signals are going to fade in from zero and fade out to zero. Interpolation to zero is the "right" thing to = do. On the other hand, if you are extracting a bit of audio, performing some manipulation, and re-inserting the audio, then you might need to think carefully about whether mixed sample rates and the resulting = interpolation are going to give you the continuity you are expecting across the = splices. -Roger ```

 [Audacity-nyquist] RE: Audacity-nyquist digest, Vol 1 #65 - 1 msg From: Roger B. Dannenberg - 2005-08-08 17:46:26 ```> I am using the ramp function as shown in the code below. When I=20 > run it on test data (e.g., a constant signal of amplitude > 0.5) it glitches in the last few samples of the selection=20 > that I apply it to. It smoothly ramps to the final volume=20 > as it should, then suddenly jumps to fairly random value.=20 The RAMP function is computed at the default control rate. When you = multiply by a higher sample rate signal, e.g. your audio selection, the ramp is interpolated. To interpolate, you look ahead one sample to see where the signal is going and linearly interpolate to that point. This works fine until you get to the end of the ramp. To look ahead at the end of the = ramp, you must look beyond the last sample. By definition, when a Nyquist = signal terminates, i.e. reaches the last sample that is specified by some primitive, the signal goes to zero. You can read as many additional = samples as you want, and they will all be zero. So when you interpolate the last sample period of a ramp, you will look ahead and find a zero, and the interpolated samples will linearly interpolate from 1 to 0. The default control rate is 2205, so you'd expect to see a return to zero over 20 samples if your selected signal sample rate is 44100. To avoid some of the problems caused by interpolation, RAMP is extended = by one sample. While most Nyquist primitives have a default duration of 1 second, RAMP's default duration is 1 second + 1 sample, so if you write, say, (MULT (OSC C4) (RAMP)), you will get a 1 second signal (due to the duration of OSC), and you will not see the final fall from 1 to 0, which would occur between samples 2205 and 2206 (beyond 1s) of the RAMP. Unfortunately, there seems to be some subtle interaction with the way Audacity defines the Nyquist environment and how Audacity interprets the result of a signal expression, and I assume this is causing the problem. = One simple fix may be to change the RAMP sample rate, e.g. (mult s (control-rate-abs (snd-srate s) (ramp))) Or, since RAMP extends its duration by one sample by default, it's = probably better to use PWL: (mult s (control-rate-abs (snd-srate s) (pwl 1 1))) By computing the ramp at the same rate as the audio signal, there will = be no interpolation and Nyquist will not look beyond the ramp to find any = zeros. Having introduced the idea of computing control functions at the audio sample rate, I should add that this is almost NEVER necessary when generating signals, because most audio signals are going to fade in from zero and fade out to zero. Interpolation to zero is the "right" thing to = do. On the other hand, if you are extracting a bit of audio, performing some manipulation, and re-inserting the audio, then you might need to think carefully about whether mixed sample rates and the resulting = interpolation are going to give you the continuity you are expecting across the = splices. -Roger ```