[Audacity-nyquist] Re: Audacity-nyquist digest, Vol 1 #66 - 1 msg

[Bruce S. <bru...@gm...>]

Thanks, Roger!  Using pwl instead of ramp seems to have fixed the
problem.  The supplied plugins "Cross Fade In" and "Cross Fade Out"
should be adjusted to incorporate this.

For the benefit of others reading this, there was a typo in your code.
It should be:
(mult s (control-srate-abs (snd-srate s) (pwl 1 1)))

And just in case anyone is interested the plugin I was really writing
was a delete with a linear crossfade.  The code is given below.  It's
my first Nyquist code of any significance, and I'd be interested in
any feedback on it.

*** plugin starts here ***
;nyquist plug-in
;version 1
;type process
;name "Delete with Crossfade"
;action "Crossfading"
;info "Deletes selection and crossfades the ends"
;control fade-length "Crossfade length" real "s" 0.20 0 10

(setq +max-seconds+ 600)
(setq +max-samples+ (* +max-seconds+ 44100))

(defun snd-range (snd)
  (snd-extent snd +max-samples+))

(defun process-channel (channel)
  (let* ((range (snd-range channel))
         (length (cadr range)))

    ; Check if selection is long enough
    (when (> (* 2 fade-length) length)
      (progn  ; need progn because Audacity does not allow multiple
expressions in body of when
        (format t "Selection of length ~a not long enough for cross
fade of ~a~%" length fade-length)
        (return-from process-channel channel)))
   =20
    ; Extract beginning and end of selection
    (let* ((fade-length-ratio (/ fade-length length))
           (beg-sound (extract 0 fade-length-ratio channel))
           (end-sound (extract (- 1 fade-length-ratio) 1 channel)))

      ; Crossfade the beginning and end, discarding the middle
      ; We use pwl instead of ramp because ramp has an extra sample at
the end which can cause glitches
      (let* ((end-ramp (control-srate-abs (snd-srate s) (pwl
fade-length-ratio 1)))
             (beg-ramp (diff (const 1) end-ramp)))
        (sum (mult beg-sound beg-ramp)
             (mult end-sound end-ramp))))))

; Stereo files require special processing because not all sound
functions support stereo
(if (arrayp s)
  (progn
    (let ((out-array (make-array 2)))
      (dotimes (i 2)
        (setf (aref out-array i) (process-channel (aref s i))))
      out-array))
  (process-channel s))
*** plugin ends here ***

On 8/8/05, aud...@li...
<aud...@li...> wrote:
> Send Audacity-nyquist mailing list submissions to
>         aud...@li...
>=20
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/audacity-nyquist
> or, via email, send a message with subject or body 'help' to
>         aud...@li...
>=20
> You can reach the person managing the list at
>         aud...@li...
>=20
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Audacity-nyquist digest..."
>=20
>=20
> Today's Topics:
>=20
>    1. RE: Audacity-nyquist digest, Vol 1 #65 - 1 msg (Roger B. Dannenberg=
)
>=20
> --__--__--
>=20
> Message: 1
> From: "Roger B. Dannenberg" <rb...@cs...>
> To:  <aud...@li...>
> Date: Mon, 8 Aug 2005 13:45:36 -0400
> Subject: [Audacity-nyquist] RE: Audacity-nyquist digest, Vol 1 #65 - 1 ms=
g
> Reply-To: aud...@li...
>=20
> > I am using the ramp function as shown in the code below. When I=3D20
> > run it on test data (e.g., a constant signal of amplitude
> > 0.5) it glitches in the last few samples of the selection=3D20
> > that I apply it to. It smoothly ramps to the final volume=3D20
> > as it should, then suddenly jumps to fairly random value.=3D20
>=20
>=20
> The RAMP function is computed at the default control rate. When you =3D
> 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 =3D
> ramp,
> you must look beyond the last sample. By definition,  when a Nyquist =3D
> 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 =3D
> 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.
>=20
> To avoid some of the problems caused by interpolation, RAMP is extended =
=3D
> 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.
>=20
> 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. =
=3D
> One
> simple fix may be to change the RAMP sample rate, e.g.
>=20
> (mult s (control-rate-abs (snd-srate s) (ramp)))
>=20
> Or, since RAMP extends its duration by one sample by default, it's =3D
> probably
> better to use PWL:
>=20
> (mult s (control-rate-abs (snd-srate s) (pwl 1 1)))
>=20
> By computing the ramp at the same rate as the audio signal, there will =
=3D
> be no
> interpolation and Nyquist will not look beyond the ramp to find any =3D
> zeros.
>=20
> 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 =
=3D
> 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 =3D
> interpolation
> are going to give you the continuity you are expecting across the =3D
> splices.
>=20
> -Roger
>=20
>=20
>=20
>=20
> --__--__--
>=20
> _______________________________________________
> Audacity-nyquist mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-nyquist
>=20
>=20
> End of Audacity-nyquist Digest
>