Nyquist Plug-ins Reference
This page offers a detailed look at the structure and syntax of Nyquist Plugins. It is intended for people who wish to write their own plugins.
|
Related article(s):
Please note: Nyquist supports both a LISP syntax and a more conventional syntax called SAL. You can choose a manual from a link above based on which syntax you are using. SAL only works in Audacity 1.3.8 or later.
|
Contents
- 1 Overview
- 2 Nyquist Plugin Header
- 3 Nyquist Plugin Widgets
- 4 Nyquist Variables
- 5 Variables and Property Lists
- 6 The *SCRATCH* Symbol
- 7 Version 4 Property Lists
- 8 Stereo Tracks
- 9 Return Values
- 10 Math Functions
- 11 Nyquist Workbench
- 12 Nyquist Apropos Plugin
- 13 Bugs
The Audacity Nyquist Interface is implemented in the following files in the Audacity source code:
- audacity/src/effects/nyquist/Nyquist.cpp
- audacity/lib-src/libnyquist/nyx.c
Overview
Nyquist plugins are simple text files ending with the filename extension ".ny". When Audacity starts, it looks in a plugins directory for files and automatically adds the effects it finds there to the Audacity menus. The plugins can be written in either LISP or SAL syntax. When the user selects the plugin from the menu, Audacity causes the Nyquist language runtime system (built into Audacity) to run the plugin code to process or generate audio. You can also compute strings to display to the user or compute labels to be shown on a new label track.
Before running the plugin, Audacity parses some of the plugin text looking for specially formatted comments that describe "widgets" -- controls that the user can use to set parameters for the effect. For example, your plugin can display a slider to control volume or filter frequency. Values from the widgets are passed through global variables to the plugin.
For a full description of the plugin language, read the Nyquist Reference Manual. There are, however, some details of how plugin code is processed that is unique to plugins and therefore not covered in the Nyquist manual. The main thing to know is that the variable s is the selected sound. This is probably the main input to your effect. The second thing to know is how sound is returned from Nyquist to Audacity.
SAL syntax is inherently command oriented. A SAL plugin should consist of a sequence of SAL commands including define commands to define variables and functions. There must be a function definition for main. After performing the commands in sequence, Audacity calls main (with no parameters). The value returned from main is the result of the plugin (normally this should be a sound).
One exception to this is the effect. Since defining main just to evaluate and return a simple expression is so awkward, you can simply type
return expression
Normally, this is not a legal statement as a top-level command in SAL, but in , special processing embeds the return statement into a declaration of function main, which is then called. This trick also works for regular plugins, but defining main is the preferred style.
For LISP syntax plugins, Lisp expressions are read and evaluated one-at-a-time. The value returned by the last expression is the result of the plugin. The same semantics applies to the effect. There is only one "Nyquist Prompt" for both SAL and LISP syntax. Audacity looks for the first non-space character that is not part of a comment. If it is an open paren "(", then the code is assumed to be LISP; otherwise, SAL is assumed.
The "Nyquist Prompt" effect is not equivalent to plugins because Audacity processes the plugin header information from plugin files, but the "Nyquist Prompt" effect ignores them (they are just comments).
Nyquist is a superset of the XLISP programming language and as such is limited to single-byte ASCII characters. The results of using characters outside the range of ASCII 32 to 126 in Nyquist plugins are unspecified. While the use of characters outside of this range may work satisfactorily for personal use on some operating systems, plugins for public distribution must currently be written using only standard characters (ASCII characters 32 to 126). This applies to plugin code, comments and string data.
Nyquist Plugin Header
The Nyquist Lisp interpreter as well as the Nyquist SAL compiler in contrast recognize everything after the first semicolon up to the end of the line as a comment and just simply ignores it. So in the Nyquist code, below the plugin header, comments can also be started with several semicolons in a row.
;nyquist plugin ;version version ;type type ;name "name" ;action "text" ;preview option ;categories "text" ;info "text" ;control parameters ;codetype type ;debugflags flags
The "preview", "categories", "info", "control", "codetype", and "debugflags" lines are optional and can be omitted.
Required plugin header lines
nyquist plugin
Tells Audacity "this is a Nyquist plugin":
;nyquist plugin
version 1
Only the Slider widget is supported:
;version 1
version 2
The Text input widget was added in Audacity 1.2:
;version 2
version 3
The multiple-Choice widget was added in Audacity 1.3:
;version 3
version 4
Additional global variables were added in Audacity 2.0.7 to pass additional information from Audacity to Nyquist.
;version 4
type generate
Plugin appears in the Audacity menu:
;type generate
type process
Plugin appears in the Audacity menu:
;type process
type analyze
Plugin appears in the Audacity menu:
;type analyze
name
Name of the plugin as it will appear in the Audacity menu:
;name "name"
Note that for plugins to be used in Chains, the colon character ":" cannot be used (as it is a special character in the Chain text file).
action
Text to be displayed while the plugin is working:
;action "text"
Optional plugin header lines
preview
Process type plugins may be given a preview button by including this header:
;preview enabled
An alternative (functionally identical) version of this header is:
;preview true
Preview may be used in process or generate type effects. Note that Preview applies the plug-in code to a mix of the selected tracks and not to the tracks individually.
categories
LV2 categories, see Categories below.
;categories "text"
info
Text to be displayed at the top border of the plugin window:
;info "text"
A two-character sequence "\n" within "text" causes a line break. It is not possible to "quote" a line break in the plugin code with a backslash '\' at the end of the line. In the plugin header, the text in the "action" and "info" lines must be written in one single line.
control
Define a plugin widget. There can be several "control" lines in the plugin header. Add one for each widget to appear in the dialog box -- see Nyquist Plugin Widgets below:
;control parameters
codetype lisp
The syntax of the plugin is Lisp. This is the default if the "codetype" line is missing:
;codetype lisp
codetype sal
The syntax of the plugin is SAL. The default is "lisp".
;codetype sal
debugflags
See Internal Debug Options below:
;debugflags flags
LV2 categories were introduced in Audacity 1.3.6 as part of "Google Summer of Code 2008".
Categories were unpopular with the majority of users because of the extra navigation involved to reach the effects, and were withdrawn in from 1.3.7 onwards. Categories will not be re-introduced until it is provided with a way by which the user can turn the grouping on and off in the interface.
So, the "categories" header line is currently optional.
There is an optional "debugflags" line available, which skips the plugin window and directly executes the plugin code, so if a "debugflags" line is found in the plugin header no user-interaction is possible.
Set *tracenable* to true. The plugin behaves as if the "Debug" button was clicked by the user. This is the default:
;debugflags trace
Set *tracenable* to 'false'. The plugin behaves as if the 'OK' button was clicked by the user:
;debugflags notrace
Set *sal-compiler-debug* to true. This prints the compiler's translation of SAL to LISP before evaluating the translated code:
;debugflags compiler
Set *sal-compiler-debug* to 'false'. This is the default.
;debugflags nocompilerIn the Nyquist Workbench, the "compiler" and "nocompiler" debugflags control whether the generated Lisp code from the SAL compiler will be sent to "stdout" or to the output window in the Nyquist Workbench.
Nyquist Plugin Widgets
Every ";control" line gets parsed by Audacity into several tokens, where each token is separated by one or several whitespaces:
| ;control | var-name | text-left | widget-type | text-right | initial-value | minimum | maximum |
|---|---|---|---|---|---|---|---|
| ;control | symbol | string | int | string | integer | integer | integer |
| ;control | symbol | string | real | string | float | float | float |
| ;control | symbol | string | string | string | string | - | - |
| ;control | symbol | string | choice | string | integer | - | - |
Italic words in the table denote data types. Because tokens are separated by whitepace, strings containing whitespace must be written within quotation marks. Do not try to memorize this table, use it as a reference. The detailed syntax for each widget type is described in the following sections.
Slider Widget
Slider widgets are supported in all Audacity Nyquist plugin versions.
;control variable-name "text-left" variable-type "text-right" initial-value minimum maximum
- variable-name - a Lisp symbol.
- text-left - text that will appear to the left of the slider.
- variable-type - a "number" type, either int or real:
- int - integer [FIXNUM, an XLISP number without a dot]
- real - floating point [FLONUM, an XLISP number with a dot]
- text-right - text that will appear to the right of the slider.
- initial-value - variable value [and slider position] at the first start of the plugin.
- minimum - numerical variable value when the slider is moved to the left border.
- maximum - numerical variable value when the slider is moved to the right border.
The variable value [the slider position] can be referenced by the variable name in the plugin code.
A text input box to the left of the slider allows the user to type in a value via the keyboard. Note that typed input is validated only against the data type (integer or floating point) and it is up to the plugin programmer to catch values typed in by the user that are outside of the slider range.
Text Input Widget
The text input widget is supported in plugins version 2 or above.
;control variable-name "text-left" string "text-right" "initial-string"
- variable-name - a Lisp symbol.
- text-left - text that will appear to the left of the text input field.
- text-right - text that will appear to the right of the text input field.
- initial-string - the string will appear inside the text field.
The text typed in by the user in the text field of the plugin window can be referred as a string variable from within the plugin code. All string characters are valid, though care must be taken with escape characters if the string is to be evaluated.
Examples how to use the text input widget can be found in the source code of the Apropos Plugin.
Multiple-Choice Widget
The multiple choice input widget is supported in plugins version 3 or above.
;control variable-name "text-left" choice "string-1,string-2,..." initial-value
- variable-name - a Lisp symbol.
- text-left - text that will appear to the left of the multiple-choice list.
- string-1,... - for every string an entry in a list to choose from will be produced.
- initial-value - the number of the list entry that will be displayed as the default choice at the first start of the plugin.
The list entries string-1, string-2, etc. are internally represented by integer numbers. The first, top-most list entry string-1 will be represented by the number 0. The list entry chosen by the user can be determined by the integer value of the variable from within the plugin code.
Examples how to use the 'choice' widget can be found in the source code of the Apropos Plugin.
Nyquist Variables
The variables given from Audacity to Nyquist are defined in the file "audacity/lib-src/libnyquist/nyx/nyx.c" in the Audacity source code.
The following variables are given from Audacity to Nyquist:
- *TRACK* (version 4) - the Audacity sound [the selected part of the Audacity audio track]. The *TRACK* variable also has a list of "properties" that pass additional information to Nyquist.
- *SYSTEM-DIR* (version 4) - A variable with a list of properties relating to the file system.
- *PROJECT* (version 4) - A variable with a list of properties relating to the current Audacity project.
- *SELECTION* (version 4) - A variable with a list of properties relating to the current selection.
- *SCRATCH* - a symbol whose value and property list are preserved from one effect invocation to the next.
- S (version 1, 2, 3) - In process and analyze type plugins this is the Audacity sound [the selected part of the Audacity audio track]. In generate type plugins "S" is the Adagio rotation for a quarter note (float value 0.25).
- S (version 4) - Adagio rotation. A quarter note (float value 0.25).
- LEN - the number of samples contained in the Audacity sound.
- *SOUND-SRATE* - the sample frequency of the Audacity track.
- *CONTROL-SRATE* - the sample frequency of the control signals (such as those created by piecewise approximations. By default 1/20 of the sample rate of the track.
- *WARP* - information that communicates start-time and duration to Nyquist functions. In Audacity, the start-time is always considered to be zero (regardless of the actual start time of the selection) and the duration indicates the duration of the selection. *warp* should not normally be accessed directly.
- *FILE-SEPARATOR* - The character that separates directories in a path, e.g. "/" for Unix, ":" for Mac, and "\" for Win32.
The length of the sound in seconds can be computed one of the following ways:
(/ len *sound-srate*) ; in LISP (get-duration 1) ; in LISP
len / *sound-srate* ; in SAL get-duration(1) ; in SAL
Variables and Property Lists
In general terms, a variable is a symbol which contains a value. The symbol can be any valid name, and its value may be changed (hence "variable"). In Nyquist, the value may be of any data type (for example, a number, a character, or even a sound) and may be changed from one data type to another. Unlike some programming languages, variables do not need to be declared before use - they can just be set, and then they exist.
Setting the value of a symbol "binds" the value to the symbol. A symbol that has no value (not even "nil") is said to be "unbound".
In addition to the value of a symbol, we can also attach properties. This is a way of associating a list of items, each with their own value, to a single variable. Each item is called a key or indicator, and we can give each key a value. This list of items is called a "property list" (or plist for short).
To get the value of a property, we use the GET command.
When getting the value of a property, we do NOT want to evaluate either the variable (symbol) or the key symbol, so we must "quote" both symbols to prevent evaluation.
(GET 'varaiable-name 'property-name) ; Lisp syntax
set v = get(quote(varaiable-name ), quote(property-name)) ; SAL syntax
As an example, if we have a variable called *TRACK* (which we do in version 4 plugins), and it has a property called NAME (which it does), then we can "get" the value of that property with:
(GET '*TRACK* 'NAME) ; Lisp
return get(quote(*TRACK*), quote(NAME)) ; SAL
The *SCRATCH* Symbol
(version 3 or above - Audacity 1.3.9 or later)
*SCRATCH* is a global symbol, which is not deleted in-between plugin runs.
It provides a way for information to survive from one invocation of a plugin to the next. However, you should not rely on the "value" of *SCRATCH* beyond a single invocation of a plugin as it could be overwritten by another plugin. It is better to use property lists of *SCRATCH*. That way, you get a whole name space rather than a single variable name, and with careful naming of the property keys, name collisions can be avoided.
To pass data from plugin "effectX-partA" to "effectX-partB":
1. Assign a property name based on the effect name, e.g.: 'EFFECTX [or in SAL, which does not support the single-quote notation of LISP, write QUOTE(EFFECTX). ]
2. "effectX-partA" should delete any old property value:
exec remprop(quote(*SCRATCH*), quote(effectx)) ;; in SAL
(remprop '*SCRATCH* 'effectx) ;; in LISP
3. "effectX-partA" should compute a new property value v and save it:
exec putprop(quote(*SCRATCH*), v, quote(effectx)) ;; in SAL
(putprop '*SCRATCH* v 'effectx) ;; in LISP
4. "effectX-partB" should access the property using:
set v = get(quote(*SCRATCH*), quote(effectx)) ;; in SAL
(get '*SCRATCH* 'effectx) ;; in LISP
5. When "effectX-partB" finishes, it should remove the property:
exec remprop(quote(*SCRATCH*), quote(effectx)) ;; in SAL
(remprop '*SCRATCH* 'effectx) ;; in LISP
But there may be cases where you do some analysis and want to use the analysis data multiple times. You might even have multiple analysis plugins operating on different inputs to collect data to feed into a plugin with multiple inputs. In this case, which might be quite common, you should not call REMPROP(), but this has the problem of leaving data on the *SCRATCH* property list indefinitely.
In cases where *SCRATCH* data is not deleted immediately after use, and where there is the potential to leave large amounts of memory there, there should be another effect, e.g. "effectX-partCleanup", that simply calls:
exec remprop(quote(*SCRATCH*), quote(effectx)) ;; in SAL
(remprop '*SCRATCH* 'effectx) ;; in LISP
allowing the user to explicitly free up any data stored on the 'EFFECTX property. It would be reasonable to omit the "effectX-partCleanup" effect if the data stored on the property list has a maximum size of, say, 10KB. The problem we want to avoid is properties with unbounded size getting left in the heap until Audacity is restarted.
Version 4 Property Lists
In version 4 plugins, property lists are defined for the global variables *TRACK*, *SELECTION*, *PROJECT* and *SYSTEM-DIR*. Version 4 plugins require Audacity 2.0.7 or later.
*TRACK*
Value: The sound from a selected mono audio track, or an array of two sounds from a selected stereo track (see Stereo Tracks below).
- INDEX
- NAME
- TYPE
- VIEW
- CHANNELS
- START-TIME
- END-TIME
- GAIN
- PAN
- RATE
- FORMAT
- CLIPS
*SELECTION*
Value: Unbound.
- START
- END
- TRACKS
- CHANNELS
- LOW-HZ
- CENTER-HZ
- HIGH-HZ
- BANDWIDTH
- PEAK-LEVEL
*PROJECT*
Value: Unbound.
- RATE
- TRACKS
- WAVETRACKS
- LABELTRACKS
- MIDITRACKS
- TIMETRACKS
*SYSTEM-DIR*
Value: Unbound.
- BASE
- DATA
- HELP
- TEMP
- PLUGIN
Stereo Tracks
If a sound from an Audacity stereo track was given to Nyquist, the s variable contains an array of sounds. Because all Nyquist "snd-..." low-level functions only can process mono signals, to use such a function, the s array first must be split into single mono signals and afterwards be re-combined into an array before it is given back to Audacity.
In Sal, one could write:
if arrayp(s) then return vector(snd-function(s[0]), snd-function(s[1])) else return snd-function(s)
Or in LISP, one could write:
(if (arrayp s)
(vector
(snd-function (aref s 0)) ; left stereo channel
(snd-function (aref s 1))) ; right stereo channel
(snd-function s)) ; mono signal
- (arrayp s) - tests if 's' is an array
- (vector ... ) - re-combines the two mono signals into a stereo signal. A "vector" is an one-dimensional array
- (aref s 0) - the left stereo channel [the 0-th slot of the array]
- (aref s 1 - the right stereo channel [the 1-st slot of the array]
Important: The Nyquist interface within Audacity can handle a maximum of two channels simultaneously [Audacity stereo tracks]. If in Audacity more than one audio track were selected, each of the selected tracks will be given sequentially, one after the other, with a maximum of two channels simultaneously [stereo] to Nyquist for processing. It is not possible with Nyquist in Audacity e.g. to copy audio signals from one Audacity track into another track [Audacity 1.3.9, November 2009].
multichan-expand
In the "nyquist.lsp" file in the Audacity "nyquist" sub-directory there is a function "multichan-expand" defined that simplifies the handling of multi-channel sounds [e.g. stereo tracks]:
(multichan-expand function &rest arguments)
So the "arrayp" constuct from above can also be written:
return multichan-expand(quote(snd-function), s) ;; in SAL
(multichan-expand #'snd-function s) ;; in LISP
This looks a bit more cryptic and reads less intelligibly [to some], but it can help to clean up the code in long-winded audio processing functions.
Return Values
The result of the last computation within the plugin code will be given back from Nyquist to Audacity. According to the data type of the Nyquist return value one of the following actions will be invoked in Audacity:
Sound: The sound will be re-inserted into the selected part of the Audacity track. If the returned sound is shorter or longer than the original sound, the selection will be reduced or augmented. If a mono sound is returned to a stereo track, so in both channels of the stereo track the same mono sound will be inserted. If a stereo sound is returned to a mono track, an error message will be displayed.
String: A dialog window will appear with the string being displayed as text.
Number: A dialog window will appear with the number being displayed as text.
List: If a specially formatted list is given back to Audacity, a label track will be created below the audio track(s).
For point labels the format is:
((number "string") (number "string") ... )
The list to create a label track must contain one or more lists, each of which must have:
- number - (an integer or float) is the time in seconds from the beginning of the Audacity selection, where the label will appear.
- "string" - a string to be displayed in the label's text field.
For region labels (Audacity 1.3) each label list must contain two int-or-float elements, one for the start and one for the end of the label region.
((number number "string") (number number "string") ... )
Math Functions
n-th power of x:
power(x, n) ;; in SAL (power x n) ;; in LISP
n-th root of a number:
power(x, 1.0 / n) ;; in SAL (power x (/ 1.0 n)) ;; in LISP
n-th root of a sound s:
return s-exp(s-log(s) * (1.0 / n)) ;; in SAL (s-exp (mult (s-log s) (/ 1.0 n))) ;; in LISP
n-th root with two sounds x and n:
return s-exp(s-log(x) * s-recip(n)) ;; in SAL (s-exp (mult (s-log x) (s-recip n))) ;; in LISP
Nyquist Workbench
The Nyquist Workbench gives the ability to run arbitrary Nyquist code in Audacity from a graphical IDE.
The Nyquist Workbench is an Audacity module, previously available as standalone source code from http://audacity.homerow.net/index.php?dir=modules%2F.
Nyquist Workbench is included in the Audacity HEAD source code at \lib-src\mod-nyq-bench and has now moved from the Tools menu to the View menu.
Linux
The following steps are correct for Linux as of July 2013 building from the Audacity HEAD development code.
1. Type "./configure " in the Audacity source code directory:
./configure
2. If configure completes successfully, compile Audacity. In the Audacity source code directory type:
make
If you are having problems at either of the above points, try the Compiling Audacity Step by Step Guide.
3. If 'make' completes successfully, still in the Audacity source code directory, type:
sudo make install
which by default installs Audacity to "/usr/local/share/audacity".
4. Open /lib-src/mod-nyq-bench/Makefile and set the required AUDACITY_DIR variable at the top of the Makefile to the base of your Audacity source code directory, for example:
AUDACITY_DIR ?= /home/edgar/downloads/audacity
5. After saving the changes in the Makefile, compile the Nyquist Workbench. In the Nyquist Workbench directory type:
make
After "make" has finished you should see a message like:
NyqBench.so has been copied to /home/edgar/downloads/audacity/modules
6. On Linux, the Audacity "make install" does not copy the "modules" directory, so change to the base of your Audacity source code directory, then type:
sudo cp -r modules /usr/local/share/audacity
This copies the "modules" directory with its complete contents from the Audacity source code directory to "/usr/local/share/audacity/modules". If you installed Audacity other than to /usr/local/share/audacity, point the copy command to that directory. Alternatively, you could create an "~/.audacity-files/modules" directory:
mkdir -p ~/.audacity-files/modules
then move or copy "NyqBench.so" into that "modules" directory where Audacity will find it irrespective of the location of the Audacity installation directory.
Mac OS X
This information assumes you have already followed Building On Mac and is correct as of July 2013.
- It is not currently possible to build mod-nyq-bench at the command-line using the Makefile. Therefore it is suggested that you build both Audacity and mod-nyq-bench in the Xcode IDE. First, build Audacity using the Xcode IDE.
- Next, in the "Groups & Files" column in Xcode, expand "Targets" and select "mod-nyq-bench". Right-click over the selection and choose Build "mod-nyq-bench" . Alternatively from the dropdown box top left, under the "Active Target" list, click on "mod-nyq-bench" (don't change the "Active Configuration"), then click the "Build" icon.
- Assuming you built Release Static configuration, separate PPC and i386 builds of mod-nyq-bench.so will be built in their own folder inside
<path to Audacity build>/mac/build/Audacity.build/Release Static/mod-nyq-bench.build/Objects-normal.However the build process uses lipo to create a single universal binary mod-nyq-bench.so in
<path to audacity build>/mac/build/Release Static/modules.This universal binary is the module Audacity will load.
Loading/Enabling mod-nyq-bench
As of 2.0.7-alpha (r13379, 02 October 2014), after first building mod-nyq-bench you will need to launch Audacity then enable mod-nyq-bench in Modules Preferences. Set the control to "Enable" and restart Audacity then the "Nyquist Workbench" item will be visible at the bottom of View Menu.
From r12363 (16 June 2013) until r13378, each time you launch Audacity you will be asked if you want to load mod-nyq-bench. If you choose "yes" and the build of mod-nyq-bench matches with the version string of Audacity, you should then have an additional "Nyquist Workbench" entry at the bottom of the "View" Menu.
Prior to r12363, when you launched Audacity after a first build of mod-nyq-bench, you had to enable the module in a Modules Preferences, then if so enabled Audacity would load mod-nyq-bench on next launch if it was matched with the Audacity version string.
Rebuilding Audacity and Nyquist Workbench
When you update your Audacity source code tree and rebuild Audacity on a subsequent day, you must also rebuild mod-nyq-bench.
- It is recommended to run "make clean" or "make distclean" before configuring and building Audacity.
- In Xcode on Mac, select "Audacity" under "Targets" and choose Clean "Audacity" before rebuilding Audacity.
- After building Audacity, change to the Nyquist Workbench directory, type "make clean" to remove NyqBench.so and NyqBench.o, then type "make" to rebuild NyqBench.so.
- In Xcode on Mac, select "mod-nyq-bench" under "Targets" and choose Clean "mod-nyq-bench" before rebuilding the module.
Nyquist Apropos Plugin
Because not all functions, documented in the Nyquist manual, are implemented in Audacity and also not even all Nyquist functions are documented in the Nyquist manual [Lisp is a "programmable programming language", only functions which are considered as stable are documented], it is often helpful to have a tool to find out whether a particular Nyquist function is implemented or not.
Basically only Nyquist functions beginning with "snd-..." are implemented in C within the Nyquist interpreter [in the Nyquist manual they are called 'low-level' functions], while all other Nyquist functions are implemented in the Lisp files within the Audacity "nyquist" sub-directory and can be changed, improved and extended with no need to re-compile Audacity [as long as no C-implemented Nyquist "low-level" function is needed which is not included with Nyquist in Audacity].
All Nyquist/XLISP symbols [e.g. all variable and function names] are stored in the XLISP *obarray*. To find out from within Audacity, whether a particular function is implemented or not, you can e.g. first create and select a "dummy" audio track with any generator from the Audacity menu, then open [doesn't work without a selected audio track] and copy the following line into the "Nyquist Prompt" text input field:
(print (fboundp 'snd-abs))
Important: now please click "Debug" instead of the "OK" button.
First a dialog appears telling you: "Nyquist did not return audio" [or similar]. In this dialog, click the "OK" button. Then another dialog "Nyquist output" appears with the result of the "print" function:
- T - meaning "true", function is implemented
- NIL - meaning "false", function is not implemented
I had typed this so often in the past that I have written an Audacity Nyquist "Apropos" Plugin:
Download: Apropos-Plugin
Right-Click on the plugin link, choose "save target as", and save the file "apropos.ny" file in the Audacity "Plug-Ins" sub-directory. After a re-start of Audacity you can find the "Apropos" Plugin in the menu, the only menu that works without a "dummy" audio track.
The "Apropos" Plugin offers a pattern search through the Nyquist/XLISP *obarray*. You can also choose between "Functions only", "Variables only" and "All symbols":
Note: with no search pattern [empty field], the plugin matches all symbol names.
First appears a dialog that reminds me that I have forgotten to press the "Debug" button:
In the first dialog above, just klick the "OK" button. Afterwards, but only if you have clicked the "Debug" button in the plugin window, appears the window with the results, sorted in alphabetical order:
Bugs
Details of current bugs that affect Nyquist in Audacity are listed on Bugzilla.
