Nyquist Wish List

Links to topics requesting new features or other enhancements to Audacity-Nyquist.

HTML links
https://forum.audacityteam.org/t/wish-list-html-links/15153/1
[Update: Nyquist plug-ins can now have a Help button that opens an HTML help page.]

Preview button for ‘process’ plug-ins
https://forum.audacityteam.org/t/wish-list-preview-button-for-process-plug-ins/15155/1
[Update: Done]

Pass Peak level to Nyquist
https://forum.audacityteam.org/t/re-audacity-nyquist-wish-list-peak-level/15152/1
[Update: Done]

Pass other track data
http://forum.audacityteam.org/viewtopic.php?p=127069#p127069
(and http://forum.audacityteam.org/viewtopic.php?p=191199#p191199)
(and http://forum.audacityteam.org/viewtopic.php?f=39&t=67896)

  • Track name [Update: Done]
  • Track time [Update: Done]
  • Track number [Update: Done]
  • Number of tracks selected [Update: Done]
  • Channel allocation (for mono tracks)
  • RMS [Update: Done]
  • Start time [Update: Done]
  • Envelope Points
  • Bit depth
  • Label data (from label tracks)

GUI designer module
https://forum.audacityteam.org/t/wish-list-gui-designer-module/15154/1

Text between controls for plug-in GUI
http://forum.audacityteam.org/viewtopic.php?f=39&t=38267

Scroll bars on Nyquist text output window
https://forum.audacityteam.org/t/scroll-bars-on-nyquist-text-output-window/15691/1

[Update: Done]

Access to Nyquist Prompt without generating a track first.

Selection choice boxes should expand from default size when they contain longer text.

Proposal that “Generate” type plug-ins can produce stereo, mono or no audio track.
https://forum.audacityteam.org/t/wish-list-generate-stereo-mono-or-no-audio-track/17056/1

Support for “Preset menu”.
[Update: Nyquist plug-ins now have the “Manage” button, which supports presets.
Limitation: There is as yet no way for the plug-in developer to define presets other than the “factory default”.]

(from this post https://forum.audacityteam.org/t/channel-mixer/14632/1 )

A preset menu can currently be implemented using the “Choice” widget, but the chosen preset values are not shown in the interface.
This proposal is for the sliders and other widgets to respond to the values selected in a “Preset” widget.

For example, if there are 2 sliders, the preset menu could hold values for each of those inputs. When a preset is selected, each of the sliders would change automatically to the value allocated by the preset. This would probably require that the choice widget was extended to hold value pairs.
Rather than just:

;control Variable "Select a preset from the list" choice "A,B,C" 0

there could be something like:

;control ListVariable "Select a preset from the list" preset "A,B,C" (-24 2.0)(-12 1.0)(-6 0.0)
;control varX "Input X" int "" (ListVariable 0) -48 0
;control varY "Input Y" real "" (ListVariable 1) 0.0 10.0

Where varX takes it’s value from the 0th element of ListVariable and varY takes it’s value from the next element.
If the values in ListVariable change (due to a different preset being selected) then controls varX and varY respond to the change in real time.

Not directly a “Nyquist issue”, but closely related:
Parentheses matching in Nyquist Prompt.

Ability to run an Analyze type plug-in without a selection.
For plug-ins that only generate labels it does not always make sense that there must be a selection.

Does that really make sense? What do you want to analyse if there is no selection? AFAIK a plugin that only generates labels is a Generate plugin and not an Analyse plugin, where a Generate plugin already needs no selection. Or do I have understood something wrong? This sounds irreal.

Feel free to move this question into another thread in case this will become a longer discussion.

The problem there is that if there is no selection than a Generate plug-in will create an audio track.
“Regular Interval Labels” doesn’t analyze anything but is an “analyze” type plug-in.

Probably a better solution would be for a plug-in that only generates labels to be a Generate plugin and not an Analyse plug-in, and for Generate plug-in to only produce an audio track if audio is returned.

How about a line control? E.g.

;control line

All it does is draw a horizontal line across the window at that point. It would be useful for grouping related controls.

Resizable choice controls would allow for better descriptions of the choices.

I’m not sure that it would be appropriate to use the command “;control”, but an option to add a line as an interface element, yes +1.

Agreed.

In longer plug-ins it would aid understanding and reduce the “intimidatory” effect if controls could be logically grouped into “panels” like the “static boxes” in built-in effects.



Gale

Hi, newbie here who hasn’t written any Nyquist yet but has a few ideas for my peculiar work editing narration.

I understand you can add to Generate, Analyze, and Effect menus.

My idea might require a fourth category, perhaps called Find, so it’s radical.

To wit: allow Find scripts to run even with zero-length selections; allow inspection of samples beyond the boundaries of the selection; return some values to indicate a modified range of selection.

Thus, for instance, allow a Nyquist implementation of the Find Zero Crossings command under Edit. Allow us to invent other routines that finely adjust selection boundaries based on other criteria.

I’m not sure what these commands should mean in case of multiple track selections. But for that matter, what does Find Zero Crossings mean in that case?

Thanks for the suggestions Paul.

There has previously been a suggestion of a “Tools” or “Utilities” menu (and in fact there was once a “Tools” menu in an old beta version of Audacity, but it was abandoned because at that time there was only one item in that menu). Would a “Tools” or “Utilities” menu be suitable for what you have in mind?


That may not be possible (probably isn’t possible) as it goes beyond the scope of the core plug-in support structure. In order to be able to operate on audio data, that data needs to be passed to the plug-in code. We usually don’t want to pass “all” of the audio data in the project as that could be many hours of data in each channel, so we just pass the relevant part of the data - the “relevant part” is defined as “the selection”. In order to have access to the full track, Nyquist would probably need to move from being a plug-in scripting language to being integrated into a “module”, which would probably be quite a major undertaking and probably not compatible with current Nyquist plug-ins.


Nyquist plug-ins currently have no concept of “real” (Audacity track) time. As far as a plug-in is concerned, the start of time is the beginning of the selection.
I agree that it would be a useful enhancement if Nyquist had access to the track time of the selection, which could then perhaps open up the possibility for Nyquist to redefine the selection region for the returned audio.


:smiley: Not much. When there are multiple tracks (or channels) selected, “Find Zero Crossings” does not really work unless all of the selected tracks/channels happen to have zero crossing points in the same place.

Perhaps my idea is too radical then.

Or perhaps, if there was some arbitrary, hard limit, or Preference, for the amount of lookahead and lookbehind, it would be an acceptable compromise. Pass the selection, plus two seconds max (say) of context on each side, to the routine, just as now you can supply an Effect or Analyzer with a range. Some new global variable tells you where start and end of the selection are relative to the start of the range. (That may vary because you bump against the clip or track boundary.) The routine might communicate back the new start and end of selection, relative to the start of the larger range, in samples. I think that’s how an Analyzer specifies labels?

An overgeneral ability to snoop minutes and hours of track data goes beyond what I want.

As for “Tools” or “Utilities,” I’m not particular what you call it, but I understand a Nyquist script includes a comment classifying it and determining the expected protocol of call and return. My idea requires a new kind of return.

Whatever menu it goes to, I want my new command to be bindable to a keystroke in Preferences.

Any reason to not just make the selection a bit bigger?

Yes, the precise endpoints of the selection are important data. I want that and some amount of context for calculations. I can’t select an exact second before and behind it quickly by hand. I could in principle do mental math and use the number inputs in the selection toolbar, but that’s hardly a convenience.

For instance, this is one idea I’ve had. When I edit narration, often the pauses between sentences need to be tightened. It’s a judgment call. I’d like to playback and stop exactly where I want the pause to end. (Stop and set cursor bound to a key, no problem.) Then trim the pause. I wanted to experiment with something that could deduce “end of pause after this point” as crossing some sound threshold, thus figuring the length to delete, then calculate the selection to be deleted, which might not begin at the selection but earlier to preserve the breath and on-glides of the next word. I’d enjoy the exercise of figuring this out for myself in Nyquist, if I just had the means. Then my whole operation could be four neat keystrokes: play, stop and set cursor, calculate the new selection, delete it.

A “find zero crossings” implemented in Nyquist would be another example of a useful thing, except of course it’s redundant. Except sometimes I wish I had one that worked with falling crossings instead of rising.

I see Paul’s point.
Imagine you pick a vocal part within a single tune. You want to add a reverb that is only applied to the vocals, i.e. the selection.
In order to prevent the reverb from being cut off, you need the sound that comes after the selection to mix the decaying part smoothly into the tune.
The same holds true for such things like a reversed cymbal fade-in, where the original sound is selected and should stay at the same position.
We normally can circumvent these problems by multi-track editing. It is easy for the first case whereas the second case needs quite some fiddling to align the beats properly.