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

[Paul L]

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.

[steve]

Or am I one of very few people who care about such effects, or has tried?

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.

Remind me of the status of this.

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.

[Robert J. H.]

Or am I one of very few people who care about such effects, or has tried?

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.

Rather 1 % of your 1 % or less.
How many Downloads has Audacity had over the years?

[steve]

How many Downloads has Audacity had over the years?

Tens of millions.

[Paul L]

Are we so much freer then to play with the Lisp sources? Fewer people to object!

Far more use Nyquist effects than write them, I imagine, and anything encouraging more writing in Nyquist should please many more than those authors.

[steve]

Far more use Nyquist effects than write them, I imagine,

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 )

[Robert J. H.]

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.

[Paul L]

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.)

[Paul L]

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.

[Robert J. H.]

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.