Bugzilla – Bug 631
SND-SEQ.sets global "S" to NIL
Last modified: 2018-08-20 11:51:44 UTC
SEQ fails if the second or subsequent sound is "S" (the global used by Audacity to pass sound from the selection to Nyquist. This failure is due to SND-SEQ setting "S" to NIL (which should not happen).
Closed as Invalid as the Nyquist manual clearly states: "Do not call this function. See seq in Section "Combination and Time Structure"." http://www.audacity-forum.de/download/edgar/nyquist/nyquist-doc/manual/part6.html#index587
I think I know what's going on here: 1) Audacity sets S to the input sound 2) (snd-seq (osc 60) #'(lambda (t0) (at-abs t0 (cue s)))) is evaluated, returning a sound to Audacity. The sound is "lazy" with structure containing (A) a pointer to the sound returned by (osc 60), and (B) the unevaluated list (FUNCTION (LAMBDA (T0) (AT-ABS T0 (CUE S))))) 3) Audacity sets S to NIL to remove the second reference to the sound it is about to obtain samples from (failing to do this would cause the computed sound to be retained in the LISP heap instead of going into Audacity files.) 4) Audacity extracts samples from the sound. First 1s of audio is generated from (osc 60). Then, it's time for the second part of SND-SEQ, so it evaluates the list, passing 1.0 as parameter t0. AT-ABS is a macro that eventually evaluates (CUE S), but S in NIL, so "error: bad argument type - NIL" is generated. Is this a bug? I'd say it is an unintended consequence of the original interface in which the input sound is specified by setting a global. I think the argument at the time was that this would be simpler than requiring a function definition, but it was a compromise at best. Is there a workaround? I think the best approach would be: ;; simulate a functional-style interface: (defun myfn (input) (snd-seq (osc 60) #'(lambda (t0) (at-abs 0 (cue input))))) (myfn s) [I have not tested this.] I missed this the first time around, but just for the record, SND-SEQ does NOT set S to NIL.
REOPENED so that Audacity documentation (at least) can be updated. Then perhaps we close this again.
(In reply to Roger Dannenberg from comment #2) > ;; simulate a functional-style interface: > (defun myfn (input) (snd-seq (osc 60) #'(lambda (t0) (at-abs 0 (cue input))))) > (myfn s) > > [I have not tested this.] I have, and it works as expected. Another workaround: (let ((s s)) (seq (osc 60) (cue s))) or (sim (osc 60) (at 1 (cue s))) > I'd say it is an unintended consequence of the original interface in which > the input sound is specified by setting a global ... > SND-SEQ does NOT set S to NIL Those were also my conclusions, which I think make this invalid as a "bug". James wrote: > so that Audacity documentation (at least) can be updated. What exactly needs to be updated? The Nyquist manual is not 'our' documentation, and this behaviour does not apply to standalone Nyquist. We could add a note here: http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_Reference but I'm not clear what needs to be said.
Steve wrote: > What exactly needs to be updated? > The Nyquist manual is not 'our' documentation... I'm not clear what > needs to be said. I'm not clear either! It's your call Steve... S (and the NILing of it) is peculiar to Audacity, and I'd have thought should be mentioned on our wiki page, along with the workaround. But I see S is not used that way in V4.... I'd mistakenly thought I all-too-hastily closed this bug in my Spring Cleaning, and was fixing my mistake. Restored to INVALID. If users already know not to use SND-SEQ then we're fine.