Access to Nyquist Prompt without generating a track first.
+1
I agree that having to create a track and make a selection can be an irritation when testing things, though I’m not sure how much of an issue it is for most users.
I guess the question is - is there a good reason why a selection is necessary before accessing the Nyquist prompt?
Historically I suspect that it was expected that Nyquist commands would only be used for applying effects, so it would be reasonable to require a selection, but Nyquist has proved itself to be far more versatile and I agree that it would be better if the Nyquist Prompt were available without a selection being necessary.
There is (sort of) access to Nyquist commands without a selection if the user has the “Nyquist Workbench” installed, but the Nyquist Workbench is only available if it is built from source, and it needs to be regularly rebuilt to maintain compatibility with Audacity. There’s a couple of minor bugs in it, but it is still an extremely useful tool for anyone developing plug-ins.
+1
POL
I’d forgotten that David Sky had written a Nyquist Generate Prompt that doesn’t require a selection to be in place. Each line is a text box, 5 lines only allowed. Could this be imporoved or can a single Prompt ever work both with a selection and without one?
Gale
There are other limitation to the Generate Prompt - it only works with simple commands that can be executed directly and in sequence. For example, in the Nyquist Prompt box you can enter functions, then call the functions - that does not work with the Nyquist Generate Prompt because it is really just evaluating a single line (the input lines are concatenated into a single string then evaluated). There are various other limitations, such as quotes cannot be used as they will end the string.
The best improvement is the Nyquist Workbench (which supports all types of plug-ins). It would be great to see this officially supported.
The recent modification by Edgar-rtf makes a BIG improvement to the Nyquist Generate Prompt.
https://forum.audacityteam.org/t/backslashes-and-double-quotes-in-text-input-widgets/16436/1
Many of the limitations that previously existed are resolved by this modification (it has now been submitted as a patch to the developers mailing list, so hopefully it will be committed soon).
The one major limitation that remains is that the plug-in is only capable of evaluating a single expression, so for example:
(print "Hello")
(print "World")
If run in the “Nyquist Prompt”, this will output “World” and the debug output will be:
"Hello"
"World"
but if run in the “Nyquist Generate Prompt” it will output “Hello” - the second expression (print “World”) is ignored and the debug output will be:
"Hello"
A more realistic example would be something like:
(defun test (amp)
(mult amp (osc 60)))
(test 0.5)
In this example the Nyquist Generate Prompt will produce no output and no error, because only the first expression (the “test” function) is evaluated.
Here is a new version of the Nyquist Prompt that I think overcomes this limitation.
This version supports multiple expressions, and with the benefit of Edgar’s patch overcomes most of the limitations previously mentioned.
I have also increased the number of lines to 9, which hopefully will still fit on an 800 x 600 screen.
Yes, it can be (and has been) improved (see previous post).
No it can’t work with existing audio within a selection - the “s” global (which passes the audio from the track to Nyquist) is only available for Analyze and Process type plug-ins. The same goes for “LEN” and (get-duration …). This means that any plug-in of type “Generate” is unable to process sounds in the current selection or return sounds of the same duration - Nyquist “generate” plug-ins are totally unaware of the current selection.
Nyquist plug-ins of types “process” and “analyze” are aware of the current selection, but require a selection.
I don’t know if it is possible to modify the Audacity code so that the current selection is sent to Nyquist plug-ins of type “generate”, but I think that such a modification would break existing generate plug-ins because it would change the Nyquist Environment (so probably a bad idea).
The “Nyquist Workbench” overcomes this limitation because it can define the plug-in type.
You could fit 10 lines in on my 800 x 600 Ubuntu 10.10 system, with still a bit of space to spare.
Gale
Are you saying that you’d prefer 10 lines to 9, or is that just information that 10 controls will fit on a 800 x 600 screen?
Would “a maximum of 10 controls” be a reasonable guideline for our Conventions for Nyquist Plug-ins topic?
A couple more refinements to the Nyquist Generate Prompt.
The “category” information has been added to the plug-in header.
The plug-in now outputs the text that has been input at the top of the debug window.
(this can be very helpful for spotting typing errors in the user code).
Also increased the number of text input lines to 10.
A subtle problem still appears:
In Lisp, a comment is defined as the range from the first semicolon in a line up to the end of the line, where the end of the comment is determined by the line-break character (newline, carriage-return, or any combination ot them).
If the code ends with a line containing a semicolon, and there is is no line-break character at the end of the line, then the Lisp interpreter is unable to finish the code. The interpreter then gets stuck in “comment-mode” and throws an “unexpected end of file” error if the input stream is finished without an “end-of-comment” character.
For example, if I type only one line:
Line1: ; comment
and klick “OK”, then the “unexpected end of file” error appears in the “Debug” window.
The solution to this problem would be to change the line:
(setq nyquist-code (format NIL "(progn ~a )" input-string))
by adding a “~%” after the “~a” like this:
(setq nyquist-code (format NIL "(progn ~a~% )" input-string))
Then no more errors with unterminated comments appear in the “Debug” window any more.
Thanks - edgar
Well caught Edgar.
Slightly different fix here to avoid excess blank lines in the debug window.
generate.ny (1.31 KB)
So is it an idea to put Edgar’s fix in to generate.ny?
It was “just information” in case you thought the extra line was sensible (and I see you’ve obliged anyway) 
Only for a plug-in that had minimal text on the ;info line, else it would be too tall. Is it possible to specify a maximum number of lines of GUI-displayable code (including the ;info line) instead?
Gale
It’s an idea to replace the old generate.ny plug-in with this new one.
On my machine the height of a control looks to be very slightly more than two lines of text.
If this is the same on other machines then that would indicate a maximum of 11 or 12 controls with no info text or one less control for each 2 lines of info text.
OK I’ve committed that to the web site, but the new content for the .zip and .ny files won’t be available online until SourceForge restore the interactive shell. I made one tweak to the .ny file which was to add an “Output:” line between the input and the output in the Debug window.
You can fit 12 controls and one line of ;info text on my 800x600 Ubuntu machine with a bit to spare so I’ve added that guideline to Conventions for Nyquist Plug-ins.
Gale