I like writing complicated effects in Nyquist, and steve has suggested that some of my work might be worth recoding in C++ for a future release.
But I have been thinking of how to make the Lisp interpreter faster instead so contributors like me can leave things in the high level language! Not to equal C++ performance but at least to cut down the interpretive overhead and garbage collections.
So I have read all of the C source for XLisp and I have a few ideas. For instance: every time you exit a let or let*, some lexical environment information becomes garbage, if no closure was made over that environment. But it should be easy in the interpreter code to prove that the frames are garbage and send them straight to the free list without the expense of a complete mark and sweep.
Would such hacks be welcome? Who would test and review my changes? Or is XLisp part of Nyquist and therefore “owned” by other parties than the Audacity team?
I think that Roger would be the person to speak to. Any performance improvements that you make would benefit the standalone version of Nyquist as well as Audacity.
XLisp 2.0 is a surprisingly old minimal Lisp with edit history comments dating from the 1980s and some of those from RBD himself. I can’t discover who if anybody is maintaining it independently of Nyquist. It must be tried and trusted if not the most modern functional programming environment. Hacking it may be radical and I want to be appropriately respectful.
So I understand that the Audacity project might not want to accumulate patches to XLisp or Nyquist that get too far out of sync with what’s at CMU. But how far is “too far?” Anything at all? Is there any precedent for changing these parts of Audacity source independently of CMU?
I may have found a couple things in XLisp sources that are opportunities for real fixes of some low probability bugs – different from the enhancements I contemplate and so perhaps more acceptable for inclusion in the Audacity distribution.
My understanding is that the Audacity developers prefer to avoid modifying libraries. If there are bug fixes or enhancements discovered, then they prefer to push them upstream. If libraries are modified by Audacity then they must be maintained by Audacity, which can be a significant addition to the maintenance workload.
Nyquist is maintained by Roger Dannenberg, so he’s the person to talk to about this.
A patch may be submitted to the developers mailing list with accompanying details. Unlike the forum the developers do not respond to every post (just as you are under no obligation to respond to every e-mail that you receive), but the mailing list has an on-line archive (http://audacity.238276.n2.nabble.com/audacity-devel-f238278.html) so posts are not lost. I think that Roger Dannenberg is subscribed to that list (rbd).
“Proposals” for medium to large scale changes, or for longer term projects may be added to the Audacity wiki (see http://wiki.audacityteam.org/wiki/Category:Proposal). To do this you would need to ask Gale Andrews for a wiki account.
Audacity bugs are entered on bugzilla http://bugzilla.audacityteam.org/ This requires a bugzilla account (again I think Gale Andrews can set that up). Bugzilla is generally used for very specific bugs and enhancements rather than larger scale projects, so for example a command that causes Audacity to crash would go onto bugzilla, but a proposal to support 64 bit values in Nyquist would probably go onto the wiki.
Patches can also be posted to this forum. You may have noticed that Edgar sometimes does this. There are not many on this forum that build from the source code but it can be convenient if you just want to check if something works beyond the confines of your own machine. Edgar builds on Windows and I build on Linux.