Known bugs in the Audacity-1.3.11-beta Nyquist interface:rdb wrote: Audacity does not completely respect the Nyquist environment, e.g. when you make a selection, Audacity pretends like the beginning of the selection is at time 0. I'm not sure if this was a wise decision, but that's how it works. Also, if you return a sound that starts at, say time=1, Audacity will treat the beginning of the sound as the beginning of the selection. This might also be a bad decision, but again, that's how it works.
- 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.
- 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.
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] web.de