Tools Menu

There are two parts to this feature request. The second part is dependent on the first.

Part 1

A “Tools” menu.
Way back in the history of Audacity there was one, but it was removed, presumably because it was underpopulated.

“Tools” would include features and plug-ins that:

  1. Do not generate audio
  2. Do not require an audio selection

Currently shipped features that could go into the Tools menu:

  • Screenshot Tools
  • Regular Interval Labels
  • Metadata Editor

Other existing features and plug-ins that could go into the Tools menu:

Part 2

A “Tools” type Nyquist plug-in.

These plug-ins would include in their header something like:

;type utility

Plug-ins of this type:

  • Would not require a selection
  • Would not produce an audio track
  • Can return labels
  • Can return a message.

Currently there are a number of “tools” that need to work around the absence of this plug-in type. These workarounds are inconvenient for both users and plug-in developers. A “tools” or “utility” type plug-in would avoid the need for such ugly workarounds and would enable other useful tools to be developed (build it and they will come :slight_smile:)

Other proposed tools:

I support Steve’s proposal in its entirety.
In addition to gathering existing tools, that do not manipulate sound in one menu, it would allow us to manage our (Nyquist) plug-ins without modifying the programs preferences. That’s especially true for the majority of plug-ins that are not shipped within Audacity.

A particularity of “Type utility” Nyq plug-ins should be that they are only invoked once, no matter how many audio-tracks are selected.
At the moment, it is so that the quick calculator returns 5 times the same result, when 5 tracks are selected. With plug-ins that only do set up another’s effect behaviour it is even worth because these do a lot of file I/O operations.
Maybe there could still be some data transferred, not any sounds, but the current path names to the application/plug-in and the preset folder, or even a copy of the Audacity.cfg content. Thus, the plug-in (manager) could setup its corresponding effect with respect to the global settings.

Would that be a natural consequence of “not requiring an audio track”?
Certainly for the plug-ins mentioned in the first post, this behaviour would be desirable.

(The following statements refer to Nyquist plug-ins only, I hope that is clear. I deliberately do not talk about other tools for the time being.)
Other behaviours are thinkable or even preferable. When I say that tool-plug-ins should only be invoked once, I do not talk about a behaviour that is forced by Audacity. “Must nots” and restrictions are a bad point to start from.
Actually, the plug-in is called like any effect plug-in before. Even the sound of the current track could be passed on.
The big difference is that the sound can not be returned to the current track.
However, it is imagineable that the tool returns a sound (or label). In contrast to other effects, this would create a new track at the end of the track-list.
An important point for this behaviour and the one mentioned above (single invokation) is that the plug-in knows exactly in which call it is currently. A secondary important point is that the plug-in can return from a call without taking any action i.e. no sound or label is returned and no message displayed.
Let me illustrate this:
Supposed we start the Quick Calculator with 5 tracks selected. The following could happen:

  1. Audacity passes the sound (s) and a data variable with a list that includes the number of tracks selected, the present call count and other information (like the path names from my post above).
  2. The calculators knows now that he is in call 1/5 and makes hence the calculation.
  3. The tool returns now the result in a message dialog.
  4. Audacity calls the tool again and passes all data.
  5. Our smart calculator realises that it stays in the second call and returns as last expression nil - no action is taken and nothing displayed (but the debug window perhaps).
  6. All subsequent calls will also return nothing.

Another example:

  1. Again, 5 tracks are selected and we call our own mastering tool “Mix & Master”.
  2. Audacity passes its data as above.
  3. The plug-in takes s and modifies it (normalisation, dithering, resampling etc.).
  4. The result is stored in scratch and the last expression is nil - no action performed.
  5. Audacity calls the plug-in again and passes the data structure.
  6. “Mix & Master” proceeds the sound as before, mixes it withe the one already stored and saves it again in scratch
  7. In the last call, all sounds are mixed down and can be manipulated in a final step (limiter, compressor etc.) The last expression is now the sound that shall appear in a new track.

with such a strategy, all kinds of combinations are possible. A tool could also return the sound every nth call and thus produce stereo or multichannel tracks from a list of mono-tracks.
Again, these points are important or essential:

  • Normal calling of the tools (like an effect-plug-in).
  • Transmission of an additional data structure.
  • It contains: call counter, max of calls (or selected tracks), current directories/path names/preferences.
  • Label tracks are returned as before.
  • Sounds that are returned are appended as a new track.
  • if nil is returned, no (visible) action is taken.

This list is not complete and other options are conceiveable (e.g. why not return a web address for further help wiki pages etc.?).

I’m a bit cautious about loading too many “features” on what a “tools” type Audacity plug-in should be.

I would argue that the simple classification would be that:

  • If the plug-in returns audio that is derived from one or more existing audio tracks, (ie. the audio is processed and returned to Audacity) then that is a “process” type plug-in.
  • If the plug-in returns audio that is not derived from existing audio tracks (ie. the sound is “generated”) then that is a “generate” type plug-in.
  • If the plug-in does something in response to audio from one or more existing audio tracks but does not return audio, then that is an “analyze” type plug-in.

What is left is left are plug-ins that do not respond to existing audio and do not return audio. These are “tools”.

It is certainly not a luxury to pass the current selected track’s sound as well, wether the tool makes use of it or not. This decision should remain with the plug-in developer. Maybe our opinions differ in regard to what is a tool and what not. An example: my "Align “Tracks Deluxe” plug-in is rather a tool than an effect. In its simplest form, it appends (aligns end-to-end) Tracks and returns the result but pitiously not in a new track. This can’t be done with effect plug-ins. These plug-ins work always destructively. Generate plug-ins can’t do the job neither since they produce new tracks only if nothing is selected.
Ok, I could export the result to a file which is however somewhat complicated within Nyquist due to the different operating systems and no direct access to a export dialog box. Furthermore the existing plug-in types do not know when the last selected track is reached, thus no possibility to determine when the export should take place.
Analyze plug-ins can only return fairly coarse results such as text or labels. What, if I want to return a RMS curve or the spectrum of all selected tracks?
I really do not insist that a sound should be returned in a new track but it is odd that labels can be returned whereas control signals can not.

All features that we strike out will most likely be missed in the future and it is nearly impossible to reestablish them.

To a large extent this decision will be with the person that programs the feature into Audacity.

I would describe that as a “process” because it is taking existing audio from Audacity, doing something with it (processing the audio data) then returning audio data.

I’m not saying that we should strike out possibilities of what Nyquist plug-ins can do. I’m saying that just because a feature is currently missing from process, generate or analyze type plug-ins does not automatically mean that it should be bundled into a new “utilities” type.

As an example, Generate plug-ins cannot create a stereo track. That does not mean that I want a new “Tools” plug-in to be able to create stereo tracks, What it means is that I’d like Generate plug-ins to be able to create stereo tracks.

Similarly, I don’t think that just because process type plug-ins must always return the same number of tracks and channels, any plug-in that returns a different number of channels must be a “Tools” plug-in. I would like “process” type plug-ins to be able to return a different number of tracks / channels.

The gap that I see “Tools” type plug-ins filling is those effects where no audio is generated (so it’s clearly not a “generate” type ), no audio is being processed (so it’s clearly not a “process” type) and no audio is being analyzed (so it is clearly not an “analyze” plug-in).

I think that expanding the capabilities of generate, process and analyze plug-ins is a different proposition, though I agree that this needs to be considered before a new plug-in type definition can be programmed.

I mean that the decision if a passed sound from Audacity to Nyquist is used, is left by the plug-in writer. The programmer gets no head aches when he can adopt the same code as for effect plug-ins.
When I write a tool that sets up the fade-in type for a single-click effect, it is certainly no disadvantage to be able to play the chosen transition type over the current selected audio. If the user doesn’t get the result he wants, he can immediately call the setup again and choose another type.
yes, you are right with the process effects. Unfortunately, most users do not know that those effect plug-ins are internally named in this manner. They see the effect menu and probably surmise that the effects should be mainly classic (like Reverb, Chorus, Flanger etc.).
I, from my point of view, would even go further than only pass sounds to “utility” plug.ins but also pass label tracks.
Let’s say we have an audio track and have set some points in a label track. We could now select the two tracks and call a primitive sequencer plug-in. There is only a textbox where you can enter a new order for the sections of your song. Instead of “A B C D” you can enter “A A B A C C D A”. The result can be saved or given back if this feature is turned on.
I don’t look at a sequencer tool as a effect.
Unless the “Utility” plug-ins offer new and different weighted possibilities, they can as well be listed under a divider in the Help menu and do not need a special menu.

Responding to Robert J.H.

Part 1:
I think that we are broadly in agreement that a Tools menu in Audacity would be useful. It makes more sense for features/effects such as “Screenshot Tools”, Regular Interval Labels, Metadata Editor, "Nyquist Workbench, Apropos, 78rpm EQ Curve Generator, Nyquist Reference, BPM LAbels and Quick Calculator to appear in a “Tools” menu than any of the current menus.

Part 2:
I think that we are also in broad agreement that a new “type” of Nyquist plug-in would be useful. In fact to make use of an Audacity Tools menu, Nyquist plug-ins would need to specify in their header that they were “tools” so that Audacity can put them in the correct menu.

We also agree that a Nyquist “Tool” type effect should not require an audio selection and should run once only, not once per track.

Beyond that I’d rather leave discussion about details of the (currently hypothetical) tools type plug-in 'till later (and probably on the “Nyquist Plug-ins” forum) so as not to muddy the water. :wink:

There may well be users that support the idea of a Tools menu, but have no idea and no interest in the internal workings of Nyquist plug-ins and I don’t want to exclude them from this discussion.

It certainly makes sense to collect those items in a tool menu that are currently kicking about in other menus.
The help menu could be cleaned out down to 3 entries. Screenshot, Protocol and Audio Info are somehow in the wrong place there. Experimental features could also be listed under the tool menu - just like the Nyquist Workbench. If there were a macro recorder in existence, I’d know where to look for.
Nyquist plug-ins however, to which no information at all is passed is for me the worst case scenario. I’d rather prefer a data transfer in the style of effect or analyze plug-ins, maybe with a flag that forces a single invocation.

Again you are reading things into what I have not said :smiley:

I think that it makes sense for:

  • Those effects that process audio to be process type plug-ins,
  • Those that analyze audio to be analyze type plug-ins
  • Those that generate audio to be generate type plug-ins,
  • Those that do not fit in any of the above categories to be classed as “Tools” or “Utilities”.

I have said nothing about what information should or should not be passed to this new plug-in type. That is still in the “to be decided” box and is a different discussion to whether or not in principal there should be a fourth plug-in type. I am happy to participate in that discussion, but not here as that discussion goes far beyond the proposal in this topic.

The first question in hand is: Do we want and do we need a “Tools” menu?
So far there are two votes in favour.

Topic split to:

@Steve: yet again I would advise that you develop this into a Wiki Proposal rather than me just transferring it to Wiki>PFR. Please advise.


Please add the following as feature requests, then the topic can be moved to the Nyquist board for eventual inclusion in a wiki article.

A “Tools” menu for features and plug-ins that do not generate audio and do not require an audio selection. See here for examples:

A “Utility” type Nyquist plug-in that goes into the (proposed) “Tools” menu. See here for more details:


Since they are talking about tools I thought of something that I do not know if it can be achieved in Nyquist. The tools would require a change in the internal code that gives nyquist support.
Starting from this point, is there any way that the gText tools can capture the text of the controls and nyquist messages to include in the translation files of Audacity (.po)?
Reviewing the translations in Poedit I have realized that the names of any effect can be changed by simply typing manually in the .po file.

 msgid "Vocal reduction and isolation..."
msgstr "Eliminación vocal y aislamiento..."
msgid "Delay..."
msgstr "Retardo..." [/ code]
The vocal effect I have tried and the delay I have perceived in the file. This translatable string is present because in the Eco effect there is a control called Delay.
The translations are done in Spanish.

You might be glad to hear that Audacity version 2.3.0 will support the translation of Nyquist plug-ins, at least the built-in ones.
It achieves this by introducing a new comment delimiter.
apart from ; there’s now also $ to indicate that this line has to be ignored during execution.
The point is that the gettext tools can extract strings (encapsulated by a function) within such a line.
So, to make the name translatable, you would write:

$ name (_ "Delay")

and this will then appear in the *.pot or *.po file.


Can you also translate the plug-in controls and the returned messages? For example the help screens, the error messages, the values returned in an audio analyzer.

Yes, all text that is put into the

(_ ...)

function will be translatable.
Header lines (including controls) that previously started with a ; have now the dollar sign in front.
Built-in effects have no help screen any more but a help button instead, so it depends whether the help page is translated.

I would suggest that you check out the newest Alpha builds.
I don’t know how far the translation is though.


For recent alpha builds see here: