A recent feature request for Audacity was for the provision of key bindings to zoom in / out vertically on a track. This feature is already available in a limited fashion from the “Set Track Visuals” macro command.
The first step is to create a macro and add the command “Set Track Visuals”. Enable the options “VZoom Top” and “VZoom Bottom”. The numeric values for these two settings are the top / bottom of the track on a scale of +/-1 (normal track height). Thus to zoom in by a factor of 2, centred around the track’s centre line, VZoom Top should be set to 0.5, and VZoom Bottom to -0.5.
The maximum top to bottom range is +2.0 to -2.0. This limit is set internally by Audacity.
After saving the macro, a custom keyboard shortcut may be added in the usual way.
A more flexible solution
While the above is simple and effective, if you want several different zoom levels, the number of keys required for keyboard access increases rapidly. A better solution would be to have one key binding for zooming in, which may be pressed repeatedly to zoom in more, and another key to zoom out (repeatedly if necessary).
To this end I wrote a couple of Nyquist Macros; one to handle zooming in and another to handle zooming out. After installing and enabling the plug-ins, they will appear as “VZoom-In” and “VZoom-Out” in the “Tools” menu. Keyboard shortcuts may be added in the usual way.
Additional considerations
What should the behaviour be if more than one track is selected?
Zooming vertically on multiple tracks at the same time is problematic since the track’s initial zoom state may differ. The scripting command for zooming vertically applies to all selected tracks and applies the same absolute zoom level to each track. These factors can lead to unexpected / unhelpful results when applied to multiple tracks, so I decided to retain Audacity’s standard behaviour of zooming vertically on one track at a time only.
When the plug-in runs, the focused track has to be selected and all other selected tracks must be deselected, so the plug-in also restores the original track selection(s) after performing the zoom action.
Limitations
The first time these plug-ins run, they may be a little slow, after which it should be very much quicker. This is caused by Nyqust updating its command cache. The cache needs to be updated when Audacity has been updated, so this minor inconvenience will not occur very often.
If multiple tracks are selected, Audacity always returns focus to the first (topmost) selected track, regardless of which track had focus originally. This will usually not be a problem as typically you would select the track that you want to zoom and apply the effect. In this case, focus is returned to the selected track as expected.
System Requirements
These plug-ins were written for Audacity 2.4.2 or later. (They “may” work with slightly older versions, but this is untested and not recommended). The current version of Audacity at time of writing is Audacity 3.4.2.
Thanks Steve from the original feature requester.
I wonder if you could share your ideas for a good work-flow and tools when developing Nyquist plugins for audacity.
TLDR section:
My initial effort has been to look for an editor with some code-completion functionality.
I’ve tried to install the nyquist-ide via https://www.cs.cmu.edu/~music/nyquist/
but haven’t succeeded as it complains on startup my java is too old (even after updating it?!!!).
Found a Nyquist syntax-highlighter for vscode (my prefered editor): https://marketplace.visualstudio.com/items?itemName=YuxuanWu.nyquist
but I would love to have some code-completion, which requires the implementation of a language-server: https://code.visualstudio.com/api/language-extensions/language-server-extension-guide
probably too steep a mountain to climb with my current knowlege of the various technologies involved.
I noticed a post on the audacity forum from 2022: https://forum.audacityteam.org/t/text-editors-with-good-or-best-support-for-nyquist-code/63851
where the OP assumed that you as linux guy would be using wim or emacs. Emacs seems like a given as the underlying language is a LISP variant.
(Other suggestions in that thread was Notepad++, used to be my go to editor on windows before vscode, but as vscode, this also only give syntax-highlighting.)
This old post on a german audacity forum (in english): https://www.audacity-forum.de/download/edgar/nyquist/nyquist-doc/examples/emacs/main.html
links to a Emacs Init-Nyquist File: https://www.audacity-forum.de/download/edgar/nyquist/nyquist-doc/examples/emacs/how-to/init-nyquist.html
Any thougths on using emacs?
Best regards
Henrik (Siggimund) Jensen
Hi Henrik,
Some good questions here. When I find time I’ll write a detailed article on this subject, but for now here are some brief points:
The tools that I use when writing Nyquist plug-ins (“plug-ins” are specifically for running in Audacity, and I’m on Linux).
* Audacity’s Nyquist Prompt. (The quickest and easiest way to run snippets of Nyquist code).
* Firefox web browser with tabs open on the Nyquist Reference page, XLisp Reference page, and this page https://web.archive.org/web/20230405064412/https://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_Reference
* Geany IDE (or NotePad++ if I’m using Windows).
I just use LISP syntax highlighting, which is close enough to be useful.
I rarely use the official Nyquist IDE. It is good for stand alone Nyquist scripts, but I don’t find it useful for Audacity plug-ins. Since plug-ins make minimal use of imports outside of the standard library, I don’t think that an IDE is really necessary for plug-ins – just an editor and run / debug the code in Audacity.
When developing a complex plug-in, I’ll install a bare-bones version of the plug-in into Audacity, and update the plug-in in-situ in my text editor / Geany. This allows running the code after every edit (Audacity uses the updated version).
I’ve not tried that Nyquist syntax-highlighter, so can’t comment on it. I keep meaning to write a syntax highlighter for Geany, but I’ve not got round to doing that as I find basic Lisp highlighting to be “adequate”.
I’ve never used Emac. It is without doubt an excellent and extremely extensible text editor, but I don’t have the time or inclination to learn how to use it properly. For me it is NotePad++ / Geany for Nyquist, PyCharm for Python, and vs-code for occasional bits of C / C++ (Visual Studio on Windows or XCode on macOS for C/C++)
If you are familiar with vs-code, then I’d say go with that. If the Nyquist Syntax highlighter does not work well, then use LISP syntax highlighting (preferable XLISP if it’s available, but common lisp will do).
Thanks Steve
I did finally get the Nyquist IDE up and running by removing all my java RTL’s (some other tools I’ve forgot I installed soon’s gonna complain I’ll bet 😄) and installing the latest 64 bit Oracle Java sdk. (Think it was a bitness mishmash, Nyquist IDE was 64bit, my java RTL was 32-bit). The Nyquist IDE actually has some kind of awkward code-completion functionality, displayed in a separate window, but still useable for newbies like me. My initial assertion, without proof, is that it might be a good start for beginners to get an understanding of Nyquist’s standalone audio manipulation capabilities and (re)introduction to the functional paradigms (I’m going through some tutorials from the docs right now).
re syntax-highlighter on vscode: On closer inspection, think it’s mostly a highlighter for the SAL language part so not entirely useful. So yeah gonna search for some XLISP extensions.
But at my current baby steps stage I’m quite content with the Nyquist IDE as a learning tool, though a bit awkward.
PS.
On second thought, even the https://www.cs.cmu.edu/~rbd/doc/nyquist/ manual is focused on the SAL language (even though Nyquist IDE offers a translation of the code to XLISP) but that is not really beneficial for newbies so forget the part of my previous post where I assert the Nyquist IDE in combination with the docs as a good intro to Nyquist’s XLISP part. Bummer