Talk:Proposal Nyquist process effects in Chains

Terminology
There is a terminology problem because generators and analysers are all "effects" as far as Audacity is concerned. So it was agreed that Proposal should specify "Effect" type plug-ins.



Support for Analyze and Generate plug-ins in Chains
Steve July 2011: I agree that there may be occasions when it would be useful to have an Analyze or Generate type "effect" in a Chain so I would not permanently rule out that possibility, but I think it would be a fairly major divergence from the current scheme so I'd rather not confuse the issue in this proposal.

It is possible to write a Nyquist plug-in that is an Effect type plug-in that will produce labels. Such a plug-in will work with the provided patch but as Chains cannot save projects it would be pointless to use such an effect on files. Similarly it is possible to write an Effect type Nyquist plug-in that will generate audio, but as a Chain is automatically applied to the entire file it will overwrite any audio data that is already there.

I think there is a case for including Analyze and Generate plug-ins in a Chain that is to be used on the current project, but it becomes quite problematic for use on files. Perhaps (in the long term) if/when "favourites" or some kind of "macro" facility is implemented the case for Analyze and Generate plug-ins will be absorbed by that feature, leaving Chains to deal with batch processing (but I think that's moving beyond the scope of this proposal).

Support for Nyquist Prompt in Chains
Gale 13Sep11: Are we sure we don't want to include Nyquist Prompt - isn't it useful? Some think so, having stumbled across it.

Steve 13Sep11 The Nyquist Prompt is most certainly useful in the absence of anything better, (such as proper support for Nyquist Plug-ins), but I think there is an inherent flaw in trying to accommodate the Nyquist Prompt in Chains. The Nyquist Prompt is designed to allow users to run and debug code snippets. The Nyquist Prompt does not have "settings" like other effects, it has "user code" which is not saved anywhere, so a Chain that includes the Nyquist Prompt will only work until either the current session ends, or the Nyquist Prompt is used with different code. I think that this limitation undermines the usefulness of Chains as a Chain containing the Nyquist Prompt cannot (currently) be saved in its entirety.

To fully support the Nyquist Prompt it would need to be decided how to handle the user code. I would guess that it would mean writing the user code into the /Chains/ file (in effect, treating it the same way as "settings" in other effects. Apart from any potential problems of writing arbitrary code into the /Chains/ file, that code would then appear as a "Parameter" in the "Select Command" dialogue, which is not ideal for multiple lines of code.

In my opinion, a much better solution for users that want to enter custom Nyquist commands would be to write the commands in a suitable editor, add the Nyquist header data and save it as a plug-in. This just involves adding 4 lines above the users code: ;nyquist plug-in ;version version ;type type ;name "name"

This is obviously not quite as convenient as just selecting an effect to use in a chain, but it overcomes the problematic limitations of using the Nyquist Prompt in chains.

If there is demand for being able to add arbitrary Nyquist code into chains, it may be better to view that as a separate feature request so that the feature can be developed properly. In fact, we already have the Nyquist Workbench, which with a bit more development could possibly fulfil this role.

Gale 13Sep11: Yes, obviously I would assume if we supported Nyquist Prompt this time around that we would be writing the settings to a text file. Each chain has its own file (and if desired, the prompt code could be linked to in a separate file), so if arbitrary code messed up a chain it should be limited to that chain. The "Parameters" text box in "Select Command" is likely to be dispensed with, so I would see the complaint about overlong Prompt parameters as an opportunity to display them better in the "Chain" window, possibly with a wrap to prevent excessive width.

As you probably guessed, I'm mentioning this as I'm having my ear pulled by a few people, so anyway I have added their votes and more justification as I understand it to Feature Requests. I think the idea is flexibility of experimentation inside a chain (rather than outside it), without the rigmarole of inserting headers, plug-ins and restarting Audacity. So permanency of the prompt may not even be an issue for some, though it's right that the ability to be permanent should be there.

Do you envisage Nyquist Workbench replacing Nyquist Prompt in time, and how long will it be before that can happen or that Chain support can be incorporated into it? There are no plans as far as I know to even distribute the Workbench dynamic libraries with Audacity post 2.0. Is the Workbench not of equal importance with mod-script-pipe (Workbench being more "finished" and easier for the "average" person to get usefulness out of it)?

Steve 14Sep11 In its current form, the Nyquist Prompt is (IMHO) too eccentric for inclusion in Chains. However, I do see the value in there being a quick and convenient method of adding Nyquist code snippets to chains (I expect that I would use such a feature quite regularly).

When the Equalization effect is included in a chain, if custom settings are used, the user is prompted to save the settings with a name. I would envisage a similar scheme for using a future version of the Nyquist Prompt in a Chain.

I don't see the Nyquist Workbench as a replacement for the Nyquist Prompt. I think they're different tools for different jobs. The Workbench is a useful tool for writing (fairly simple) plug-ins, whereas the the Nyquist Code is well suited for running code snippets. When I'm writing a plug-in I'll frequently use both of them. For example if I want to check the syntax for a particular command it's often quicker to just try it in the Nyquist Prompt than to look it up in the manual. If I want to check what a GUI will look like, then the WorkBench is a handy tool.

Regarding the "rigmarole of inserting headers, plug-ins and restarting Audacity", I keep a "dummy" plug-in available that has the name "!test" (so it appears at the top of the list) that contains just the Nyquist headers. I can then quickly write a little plug-in without any of that rigmarole, simply by editing the "!test" plug-in.

I think we could have another proposal page to discus possible developments (post 2.0) for the Nyquist Prompt. That could include features such as support for chains, parentheses matching, support for "generate" type code and saving snippets.

Gale 16Sep11: I'd have thought running code just to check syntax was easier in Workbench - as I recall, you don't have to select track in that case? And maybe Workbench too is a better vehicle for saving code snippets?

Certainly some would find it useful to import and export code snippets into Nyquist Prompt as per Feature Requests, but it would not seem to be a prerequisite to me for basic Chain support which we know works (with serious limitations).

Of course if adding the ability to save the prompt code (which would have wider benefits than just Chains) is a disproportionate amount of work for a fringe feature, then possibly doing nothing until Prompt is improved or integrated into Workbench might be a better plan. But birds in hand are usually better than in bushes, especially if there is no intention to move Nyquist Prompt into Workbench.

Quite likely it's equally important to get Nyquist Wish List or parts of it published to Wiki Proposals?