Portable (load "somelib.lsp") -- why not?

[Paul L]

Ah, but SAL is just syntactic sugar with a parser written in Lisp! So I gathered anyway from glancing at the libnyquist directories. It does not indicate a port of Nyquist implementation.

Mr. Betz does not appear to have a very current presence on the Web. There is some "copyright" notice in the source and docs but I suppose that means I can't try to profit from modifications and that isn't my purpose.

I gathered also from sources that there are many common C code patterns implementing Nyquist functions -- and this repetitive code is generated by a Lisp program that is also there in our Audacity source tree! Though running that Lisp code is not part of Audacity build procedure, it is done once before the library is distributed. I doubt Roger would be serious about abandoning that big investment in code.

Nowadays you might do this with C++ templates, but I infer that Nyquist began to grow when C++ was not yet so popular or sophisticated.

[Paul L]

According to Wikipedia, XLisp 2.0 was the basis for Autocad's Autolisp programming language.

By coincidence, I worked for a company acquired by Autodesk. But never with the Autocad program itself.

[steve]

I recall XLisp using standard C getenv. Did it expose it as a Lisp function?

Nyquist has (GET-ENV "string").
If "string" is an environmental variable, its value is returned, else NIL.
"string" is case sensitive on case sensitive operating systems.

Then users just need to set a certain environment variable and perhaps the install can do that.

Audacity is not always "installed". Currently we only provide an installer for Windows. We also provide a ZIP package that allows users without administrative privileges to run Audacity.
If a user is able to manually set an environment variable, then they should be capable of adding an absolute path into a text file, which would be an easier and less intrusive option.

Another possible solution would be to provide a "set-up" utility (written into the Nyquist plug-in) that attempts to detect the location of the Nyquist folder. If it fails, then it prompts the user to enter the location manually and then verifies if they have entered it correctly.

These are just stop-gap workarounds for version 3 plug-ins and should not be necessary in version 4.

Have you been in touch with Roger about updating Lisp yet? What did he say?

[Paul L]

So to summarize my understanding:

XLisp is implemented in C, and defines a protocol for making outside C functions callable from Lisp, and data structures allocated by C code manipulable and garbage-collectable by Lisp.

XLisp code is distributed with Nyquist code, with no other easily discovered current authoritative repository.

Nyquist proper contains libraries compiled from C code and written to that XLisp protocol.

Nyquist's own C source is partly generated by a Lisp program, but it is Roger who runs that Lisp very infrequently, not us Audacity developers.

Nyquist also includes layers written in Lisp, using the sound libraries that are in C, and loaded into Lisp whenever you use Nyquist in an Audacity session.

This last includes SAL parsing.

[Paul L]

Roger answered some of my emails months ago when I reported some bugs in Nyquist. He has not answered my more recent proposals for source code fixes of some of them. I did not mention changes to XLisp. I understand he is a professor so surely he has many other duties!

[Paul L]

You speak, steve, as if fixing this problem is a certainty for a near term. Is that right?

I think it would be nice if .ny files in the PlugIns folder could share code in .lsp files in the same folder. That is not just a matter of users who try to program, adding paths by hand. It would have to be done once and right in the distribution.

So maybe instead of environment variables we need to use "the folder of the currently loading file" portably to interpret relative paths for nested loads.

In my summary above, I did not mention the interpretation of the magic comments at the top of .ny files. I presume this really belongs to Audacity, not libnyquist. When you say version 4.0 are you really referring to the Audacity side of that interface?

[steve]

XLisp code is distributed with Nyquist code, with no other easily discovered current authoritative repository.

Other than the 9/13/02 archives at http://www.xlisp.org/

Nyquist also contains C code from the Computer Music Toolkit library http://www.ladspa.org/cmt/

[Paul L]

But as I said, the XLisp 3.0 at xlisp.org is surely not the basis for Nyquist. It is a version of Scheme so that means much incompatibility with 2.0. And it seems nobody has maintained it in a decade. I say we ignore xlisp.org.

[steve]

You speak, steve, as if fixing this problem is a certainty for a near term. Is that right?

"Near term" is not easy to define for open source projects that are dependent on the available "free time" of unpaid contributors.

There has been some preliminary work on version 4 plug-ins this year. So far it has concentrated on the interaction between Audacity and Nyquist with particular emphasis on the Nyquist Plug-in GUI. The new features become available if the plug-in is "version 4". Compatibility is maintained for version 1 to 3 plug-ins. As an example, for version 4 plug-ins, audio is passed to Nyquist in a new "*TRACK*" global which includes a number of properties including:
NAME - track name
TYPE - track type - wave, note, label, time
STIME - track start time - should probably be selection time
ETIME - track end time - should probably be selection time
(more can be added)

but for version 1 to 3 plug-ins the old "S" global is used as now.

We have a "wish list" for new Nyquist plug-in features here: http://forum.audacityteam.org/viewtopic ... 39&t=38252
It really needs writing up and prioritising as a proposal on the wiki, but I've not had time to do that yet. If there are features missing from that wish list, please add them.

[steve]

But as I said, the XLisp 3.0 at xlisp.org is surely not the basis for Nyquist. It is a version of Scheme so that means much incompatibility with 2.0. And it seems nobody has maintained it in a decade. I say we ignore xlisp.org.

I see it as Nyquist being a fork from XLisp 2.0 and as such the maintainer of Nyquist (rbd) is free to modify it as he wishes.
Audacity implements Nyquist, but there is neither the will nor the manpower to create an Audacity branch of Nyquist. Audacity implements a slightly cut down version of Nyquist with relatively minor modifications for compatibility with Audacity. Real time processing is available in Nyquist, but Audacity does not have the framework to handle that. Similarly with MIDI support.

In general, modifications to XLisp/Nyquist should be applied upstream (refer to rbd). Implementation changes are applied within the Audacity code (refer to the Audacity developers mailing list).