Gale Andrews wrote:It's still more useful than not having Preview for generate I think.

Agreed, the generated tones are often only one track anyway.There are some problems though.- A random effect (e.g. arpeggiator or surf LFO) would not return the same sound as heard in the preview.- will the durations be handled correctly?

OTOH I think Preview should be disabled for Analyze effects, if they are incapable of returning audio.

Gale

Analyze can return audio. My latency-info for example can return a sample sound fitted to the test.The actual problem is that no extra track is returned like in the generate effects.The original should indeed not be modified but an audio track might still make sense.I have here a plug-in that transfers the selection into an audible spectrum.On Windows, I can use the play feature to listen to the spectrum, while the message box returns the 10 highest peaks and the debug screen shows all like in the plot-spectrum export.If the "Audibstrum" is passed to Audacity, this should actually generate a new track imo.

The preview feature makes here certainly sense as it allows more efficient parameter choosing (and there are a lot, some exclusively for audio as target output, e.g. contrast/whitening)

Therefore, I think the preview should be available in all effects.What's more, the new code should not impose restrictions on the returned value or their number.For instance:"ReplayGain" is a process plug-in and can either return a value or normalized audio for each track.With the restriction, only the value for the first track is displayed.It is of course desireable that a help screen should only show up once.However, this should be done per either a help button, or with a predefined help stream.We've already *standard-output* and similar ones for debug, errors and trace (which all end in the debug window).If we define *help-output*, the desired text would be send by e.g.

The Nyquist-audacity interface would realize this and stop execution after one message box--the same way it does in 2.0.7 alpha.Another advantage could be that the help text could as well be passed to e.g. the standard browser.

Let me summarize the effect of preview for two typical effects:

Proces: ReplayGainPreview with Analyze: replaygain value for all selected tracks (very useful)Analyze: Only first track returned (bad)Preview with Normalize: Tracks are handled as down-mix (makes only sense if the tracks are not mix-downs themselves)Normalize: as expected (the post-down-mix might be different from the preview, I suspect)

Analyze: WavestatsPreview: Statistics for all selected tracks (good, for this tool at least)The bad thing is that the selection is previewed inspite of the fact that a message box is returned (after ok).I wonder where Audacity catches this sound although it is not the last statement?If I place s at the end and modify it, it is correctly previewed but not if it is modified or destroyed before the text message--it just plays as if nothing had happened....

Actually, my last post was incorrect. That was from a test running an analyze type plug-in from the Nyquist Workbench.What I'm seeing when running an actual "Analyze" plug-in (from an installed script file) is that when clicking on Preview, it analayzes the preview mix, then plays the preview mix, then stops.

@Robert: Do you have a nightly build installed? I think you need to try this. I'm not sure that Preview makes sense with Analyze type plug-ins.

Robert J. H. wrote:There are some problems though.- A random effect (e.g. arpeggiator or surf LFO) would not return the same sound as heard in the preview.- will the durations be handled correctly?

For generate type plug-ins, yes the durations should be handled correctly. Unlike process and analyze plug-ins, the environment is not warped to the selection length, so "1 second" when generating is still "1 second" when previewing.

steve wrote:Actually, my last post was incorrect. That was from a test running an analyze type plug-in from the Nyquist Workbench.What I'm seeing when running an actual "Analyze" plug-in (from an installed script file) is that when clicking on Preview, it analayzes the preview mix, then plays the preview mix, then stops.

If I add a Preview button to "Regular Interval Labels" on Windows, Preview plays the Preview selection then does nothing else.

If I choose "Label Interval" in that plug-in and make that interval longer than the waveform selection, I see the error message (which states the selection length as the preview length) then when I OK the message I hear the preview then nothing else happens.

steve wrote:Just to say, although there are limitations, I think that having Preview available (even if in the end is only for process type plug-ins) is a very welcome addition.

Yes indeed, if it is available for all types Let me show you what I mean.As I've mentioned before, I've written a plug-in that emulates the plot spectrum but has an audio output, rather than a visual one.It's very easy to set the perfect values when the preview option is available.Here's a 3 min plus demonstration how one can work with the plug-in:https://www.dropbox.com/s/pd4altu783nvb ... m.mp3?dl=0

Note: Eventually, I'm only interested in the debug output in order to copy it to Excel. The actual audio spectrum is therefore undone.However, the user can select another type of output (after he's all set up with the preview). That is, he can display the peaks, spectrum flatness, centroid etc. in the message box--or hit escape if he only wanted to listen to the frequency distribution.

I think the plug-in is more suited for the Analyze menu than the Effect menu.

A simpler example might be a plug-in that shows the peak or Rms value, preview delivers the values for all selected tracks as if they were mixed.Note: the preview should of course behave like in the process plug-ins and not play the original mix after displaying text.Also, I think the preview for only one selected track should take the sample rate of this track and not the project rate. Otherwise, the returned audio is not comparable to the preview.I noticed this while preparing the above demonstration. The sample rate of the "somewhere over..." track was 10240 (in order to display integer Hz-steps in the output) and the project rate the usual 44.1 kHz. I had to change the latter to the track's rate to get the same audio output.

The preview is a wonderful expansion for Nyquist plug-ins (and the prompt), especially for single tracks.

Gale Andrews wrote:If I add a Preview button to "Regular Interval Labels" on Windows, Preview plays the Preview selection then does nothing else.

Yes that is what "appears" to happen.Nyquist does actually analyze the preview mix and returns the labels (specially formatted array of numbers and text), but Preview ignores the returned labels because we are not applying the effect. Audacity only handles returning data to tracks (audio or labels) on OK or Debug (otherwise it's doing the effect, not just previewing it).

Robert J. H. wrote:It's very easy to set the perfect values when the preview option is available.

Have you tried it with a Preview button?If so, does it work as you expect?If it does, then that would seem to be a valid use of Preview in an analyze plug-in.

Yes, I've of course tried the nightly built prior to post any comments.The mp3 above should show the actual procedure. Each time a pseudo-chirp is played, that's the preview (alt-v)The original recording is not much longer than this file, I just truncated some silent gaps inbetween screen reader outputs. With preview enabled, the work is much more efficient.

This is particularly true for filter plug-ins, e.g. finding the right notch frequency.

It would be nice if there were a special variable "*preview-mode*" with T and NIL.In this fashion, we would be able to present the right kind of output, either for preview or OK/Debug.For instance:The sound finder could tell on preview could display how many labels will be created with the current threshold etc and OK would return the labels.The program code would still be backwards compatible since the preview branch is never executed (the *preview-mode" is unbound).

Robert J. H. wrote:The mp3 above should show the actual procedure. Each time a pseudo-chirp is played, that's the preview (alt-v)

I guessed that was happening but found it very difficult to follow the screen reader at that speed - I guess it takes practice.

Robert J. H. wrote:It would be nice if there were a special variable "*preview-mode*" with T and NIL.In this fashion, we would be able to present the right kind of output, either for preview or OK/Debug.

I think that would require quite a significant rewrite of the Audacity plug-in interface, but perhaps worth keeping in mind for "version 4".