Known bugs in the Audacity-1.3.11-beta Nyquist interface

From the Nyquist Transformation Environment discussion:

Known bugs in the Audacity-1.3.11-beta Nyquist interface:

  • The value of Nyquist t0 [the ‘start’ time] does not equal to the beginning of the Audacity track, so time-warps [e.g. delays] are only possible within the Audacity selection. That’s also one of the reasons why it’s not possible to time-shift Audacity selections with Nyquist [the second more important reason is that there exists no infrastructure in the Audacity Nyquist interface to give Nyquist the possibility to do so]. As a work-around Audacity automatically extends the selection if the sound returned from Nyquist is longer then the original selection with the consequence that in a multi-track situations the time alignment between the tracks is destroyed. This is not bad in all situations, but actually nothing but a work-around.

  • Important! - In the current Auadcity-1.3.11-beta as well as in Audacity CVS HEAD, the length of the sound returned by a Nyquist plugin is still dependent of the exact mouse pointer position between two samples when the user selects the sound in Audacity. The sound returned by Nyquist sometimes has a different length than the sound selected in Audacity. This bug is depending on the mouse pointer position between two samples when the user selects the sound in the Audacity track. The bug is probably caused by a wrong mouse-pointer rounding algorithm. This bug has to the consequence that Nyquist plugins destroy the the phase coherence of the Audacity track by chance. From the Nyquist Lisp level there is no possibility to correct this, because in these situations the LEN and WARP TIME-STRETCH values are also set to the same wrong length value in the Audacity Nyquist interface, so I assume that the bug already happens if the sound is given from Audacity to Nyquist.

  • In the current Auadcity-1.3.12-beta the LEN and WARP TIME-STRETCH values with ‘generate’ plugins are not set to the length of the Audacity selection, so e.g. (osc 60) will not return a sound with the length of the Audacity selection.

A further problem, known since a very long time:

  • Nyquist in Audacity needs the possibility to read and write samples directly from/to the .au-files in the Audacity project directory and not the Audacity sound just simply bound to a memory-resident global Nyquist Lisp variable. The missing internal Audacity Nyquist file-i/o interface still is the main source of the memory problems with Nyquist in Audacity.

This problem is known since more than five years now, but there is still no solution in sight.

Maybe important to know in this context: Roger Dannenberg is the main author and maintainer of Nyquist at the CMU, but not automatically the maintainer of Nyquist in Audacity. Nyquist had been ported to Audacity by Dominic Mazzoni at a very early stage of the Audacity program, but since then Nyquist in Audacity unfortunately had been left pretty unmaintained. We have heared nothing from Dominik any more on the Nyquist lists since a very long time. Leland Lucious took the burden in 2009 to update Nyquist in Audacity to Nyquist-3.0, but since then, Nyquist in Audacity got stuck again.

Please do not misunderstand: I am very thankful to Roger Dannenberg, Dominik Mazzoni, Leland Lucious and all others who have helped to improve Nyquist in Audacity, but it also helps nothing, we have to face that the Audacity Nyquist interface after all these efforts is still in a rather crappy state. I apologize for the rant, but it makes not much sense to talk-around problems only for the sake of politeness.

To me it seems as if currently there is no maintainer of Nyquist in Audacity at all.

I myself am mainly working with Common Lisp, so to me C and C++ are ‘read-only’ languages. I can help to find bugs by reading the Nyquist and Audacity C/C++ sources and try to find out how the bugs are produced, but it is no good idea to let me change the C/C++ sources, because the result will probably be worse than before.

Question: Is there any way how we can get out of this dilemma?

If you do not want to answer here you can write directly to: edgar-rft [at]

Is this a practical problem for users, or only for plug-in developers? That determines its “priority”.

Same question, plus does this affect all plug-ins or only Nyquist? I strongly dislike being able to select in arbitrary places between samples and the “sphere of influence” determines which samples are included. I suspect this is behind quite a few problems. I’ve seen it asked how else can you cope with tracks at different rates, but I assume you would then have some kind of “dog-leg” snapping of the selection to the sample? Bug 83 (also read the attached Nabble URL) may refer.

Same question - is it a problem for users?

See Bug 87.

Largely true, now Leland has left the project. You might get Al Dimond interested, who has fixed a number of problems in the Nyquist interface since Leland left. The difference is those problems were rated as P2 bugs or higher (repeatable crashes or data loss).

You could argue that the memory problems are “P3” (meaning they will be at least “release noted” like some other Nyquist problems), but most users work round that by processing in smaller selections. And at least memory is now released after processing.

In sum, and as Leland pointed out a while ago, all of this is really “post 2.0” because most of these changes could be very destabilising.


I could look at some of this. I’m not very knowledgeable about Lisp or Nyquist, though. Over the next couple weeks I’ll be very busy, as I have been lately (moving to Seattle, starting a new job), but it sounds like these issues will still be there when I next have time. I could start on some of these issues fairly soon. Others might take some serious study.

As it stands I can’t make sense out of most of these complaints. Maybe if I did some Nyquist work it would make more sense to me.

For the selection length stuff… . Isn’t the plug-in itself responsible for the length of the sound returned? It sounds like the Nyquist interface might be presenting incorrect values to plug-ins? If that’s the bug let’s state it like that. But I’ll need to make sure the values are actually wrong. I’ve worked on similar bugs with other effects, so it shouldn’t be hard to read through the code and generate a test case for this.

I want to thank edgar for bringing this (maybe again) to everyone’s attention. His post reads as if it’s obvious how things should work and what are the bugs. I don’t think there is a formal and agreed upon description of the correct interface, so it’s hard to know whether something is a “bug” or a “feature.” E.g. t0 starting at the beginning of the selection seemed to me to be an obvious bug, but there is some justification, and if we simply state that time is relative to the selection, it becomes a “feature.” I suggest: (1) document problems with the current interface, (2) document the desired interface, (3) reach a consensus on the design, (4) produce a list of actual bugs with respect to the documented design, and (5) fix the bugs (easier said than done, but not really hard). I believe it might be possible to maintain the existing interface semantics for existing plug-ins while developing and debugging a new interface by specifying a version in the header that would default to the existing API. -Roger

Thanks, Roger. For (1) maybe draft those here, but then (1) (2) and (3) would I suggest be better as a page (or series of them) in the Wiki Proposal category. For (4) be aware of existing documented Nyquist bugs.

The better organised and connected the proposals are, the more interest there will be in fixing things. I (personally) don’t see anything here at the moment that would hold up any 2.0 release, assuming no serious user impacts.

Also there are a host of usability improvements (such as for Nyquist plug-in dialogues) that should be listed on that Wiki page (things like clickable links, multiple dialogues open at once, post-session recall of settings…)