Tools Menu

Using Nyquist scripts in Audacity.
Post and download new plug-ins.
Forum rules
If you require help using Audacity, please post on the forum board relevant to your operating system:
Windows
Mac OS X
GNU/Linux and Unix-like
steve
Site Admin
Posts: 85703
Joined: Sat Dec 01, 2007 11:43 am
Operating System: Linux *buntu

Tools Menu

Post by steve » Tue Nov 13, 2012 10:30 pm

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:

Code: Select all

;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 :))

Other proposed tools:
Learn more about Nyquist programming at audionyq.com

Robert J. H.
Posts: 3635
Joined: Thu May 31, 2012 8:33 am
Operating System: Windows 10 / 11

Re: Tools Menu

Post by Robert J. H. » Wed Nov 14, 2012 12:18 am

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.

steve
Site Admin
Posts: 85703
Joined: Sat Dec 01, 2007 11:43 am
Operating System: Linux *buntu

Re: Tools Menu

Post by steve » Wed Nov 14, 2012 12:28 am

Robert J. H. wrote:A particularity of "Type utility" Nyq plug-ins should be that they are only invoked once, no matter how many audio-tracks are selected.
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.
Learn more about Nyquist programming at audionyq.com

Robert J. H.
Posts: 3635
Joined: Thu May 31, 2012 8:33 am
Operating System: Windows 10 / 11

Re: Tools Menu

Post by Robert J. H. » Wed Nov 14, 2012 9:01 am

steve wrote:
Robert J. H. wrote:A particularity of "Type utility" Nyq plug-ins should be that they are only invoked once, no matter how many audio-tracks are selected.
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.?).

steve
Site Admin
Posts: 85703
Joined: Sat Dec 01, 2007 11:43 am
Operating System: Linux *buntu

Re: Tools Menu

Post by steve » Wed Nov 14, 2012 1:08 pm

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".
Learn more about Nyquist programming at audionyq.com

Robert J. H.
Posts: 3635
Joined: Thu May 31, 2012 8:33 am
Operating System: Windows 10 / 11

Re: Tools Menu

Post by Robert J. H. » Wed Nov 14, 2012 9:02 pm

steve wrote: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.

steve
Site Admin
Posts: 85703
Joined: Sat Dec 01, 2007 11:43 am
Operating System: Linux *buntu

Re: Tools Menu

Post by steve » Wed Nov 14, 2012 10:15 pm

Robert J. H. wrote:This decision should remain with the plug-in developer.
To a large extent this decision will be with the person that programs the feature into Audacity.
Robert J. H. wrote: my "Align "Tracks Deluxe" plug-in is rather a tool than an effect.
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.
Robert J. H. wrote:This can't be done with effect plug-ins
....
All features that we strike out will most likely be missed in the future and it is nearly impossible to reestablish them.
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.
Learn more about Nyquist programming at audionyq.com

Robert J. H.
Posts: 3635
Joined: Thu May 31, 2012 8:33 am
Operating System: Windows 10 / 11

Re: Tools Menu

Post by Robert J. H. » Wed Nov 14, 2012 11:20 pm

steve wrote:
Robert J. H. wrote:This decision should remain with the plug-in developer.
To a large extent this decision will be with the person that programs the feature into Audacity.
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.

steve
Site Admin
Posts: 85703
Joined: Sat Dec 01, 2007 11:43 am
Operating System: Linux *buntu

Re: Tools Menu

Post by steve » Thu Nov 15, 2012 12:50 pm

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. ;)

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.
Learn more about Nyquist programming at audionyq.com

Robert J. H.
Posts: 3635
Joined: Thu May 31, 2012 8:33 am
Operating System: Windows 10 / 11

Re: Tools Menu

Post by Robert J. H. » Thu Nov 15, 2012 3:58 pm

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.

Post Reply