Remind me of the status of this. As I recall, loading a file with a pathname that is not absolute is not portable across supported Audacity platforms. Why not? This sounds like a big omission and a deterrent to developing more complicated effects with Nyquist.
Or am I one of very few people who care about such effects, or has tried?
My developing DeClicker which a couple of you have received very warmly is a honkin’ big 60k of text, some of which demands splitting out into utilities.
Perhaps it would not be difficult to hack the XLisp sources a bit so that an XLisp load path environment variable is used to find files.
The proportion of Audacity users that write Nyquist scripts is tiny. I think it is a fair bet that much less than 1% of Audacity users have ever written a Nyquist script.
Using relative paths is unreliable because Nyquist does not know enough about the system that it is running on. This is on the agenda for version 4 plug-ins.
Definitely. As Audacity ships a few Nyquist effects I’d guess there would be millions of users of Nyquist effects, (so it’s important not to break them )
I don’t think that Paul wants to overthrow the Nyquist implementation completely. I find it natural to improve the performance continuously and to remove inherent bugs.
The only problem is that Audacity’s Nyquist follows one step behind the stand-alone version. The danger is that any improvements made to the current version will one day or another be overwritten by Nyquist 3.20 or so. I don’t think that Roger opposes a general improvement of Xlisp or some low-level functions that are still machine-translated. I wouldn’t worry about Xlisp, the last downloadable version has a completely changed function reservoir and goes steadily in another direction (or is in fact replaced by two other implementations of a newer date).
Anyway, Roger is the person to contact firstly.
Robert, what do you know about XLisp versions? My impression from comments in the C sources for XLisp (yes I read them all!) is that XLisp 2.0 was a very old thing developed in the 1980s and not maintained much at all. I mean the XLisp subfolder of the source, not the libnyquist sources in C and Lisp that use it.
The website XLisp.org mentions a 3.0 that was based on Scheme, not Common Lisp, which really means an incompatible language (no #’ or funcall, set! not setq, etc.) which I am sure we don’t mean to port to. That would break existing code. And besides there is no evidence that 3.0 was actively maintained since 2003.
XLisp 2.0 is a small Lisp written all in C – none of it written in Lisp itself. But Nyquist preloads many things. Incidentally that includes some basics like incf and decf and push and pop. (And why does XLisp define exp but not log? Nyquist supplies s-log.)
I am away from my home computer but I recall XLisp using standard C getenv. Did it expose it as a Lisp function?
If so it should be very easy to write a portable relative path loader that interprets “;” separated path strings in Lisp and put the few lines in misc.lsp along with the other basics like push (that are NOT documented as properly part of XLisp 2.0). Then users just need to set a certain environment variable and perhaps the install can do that. Our Nyquist sources become only slightly forked with at most one file that needs merging with Roger’s latest.
Paul, if you would have asked anything about Pascal and its inventor Niklaus Wirth, I could have served you.
Alas, I’ve no connection to David Betz and must relie therefore on the same sources as you.
XLISP 2.0 is open source and that’s probably the reason why it makes up the skeleton for Nyquist, along with the rudimentary OO-implementation.
Roger might nowadays rather pursuit a C-like implementation as the switching to the Algol-based SAL shows.
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.
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.
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?
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.
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!
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?
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.
“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: Nyquist Wish List
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.
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).
)