[ Re: Audacity 2.1.0 & 2.1.1 running on Windows Vista ].
Spitfish problem in 2.1.0 & 2.1.1 : the previewed effect is stronger than that which is subsequently applied.
When using Spitfish the de-essing effect is much stronger in the preview than when it is applied to the audio.
Hypothesis : the real-time preview is unintentionally applying the effect twice , ( i.e. an unintentional iteration) , but when the effect is applied to the audio it’s only applied the once.
I know you use many effects Trebor, so I assume that this problem is specific to Spitfish VST?
Or perhaps a control that is not responding and stuck at max? Could you check that out? (I’m on Linux so I can’t test VST effects).
I’ve only just started using 2.1.0 , so not tried a lot or effects as yet, but there are similar problems with some other VSTs , e.g. Antress “modern de-esser” has the same problem : what it sounds like in the preview is different than what the effect sounds like when applied.
Also the real-time preview often fails : initially the VST effect will produce an audible change in the sound when previewed in real-time, then after a few applications it no-longer changes the preview sound. However even in that state it will change the sound when the effect is applied. After such a failure restarting Audacity is required to get the real-time preview to work again.
The preview sound does change in quality when the controls are changed, so the controls don’t appear to be stuck.
The phenomenon is consistent with the preview applying a double-dose of the de-esser effect , but only a single dose is actually applied to the track.
On this example the difference between the last two takes is more subtle than the sptifish example above.
But I’m not imagining a difference : the spectrograms and frequency-analyses of the last two takes differ.
As you are on Windows, Trebor and many VST’s are Windows only, I think this is better in the Windows board.
As you may be aware, real-time preview does not apply latency compensation but applying the effect does, so that is one reason preview and playback of the applied effect may differ (unless you turn off latency compensation in the Manage menu > Options…).
Have you tried LISP to see if the preview has a stronger effect there?
I don’t know about “often” but yes I have experienced that with many effects, but just once or twice. There may be some effects that are more prone. Are there any effects that you find are especially prone?
Also if you are using Factory or User Presets, they are a specific cause of this - some VST’s do not preview the chosen factory or user preset unless it is chosen while playing ( http://bugzilla.audacityteam.org/show_bug.cgi?id=1084 ). In that case you don’t hear the chosen preset until you restart Audacity and that is another reason the preview differs from the applied effect.
Gale
Unchecking “Latency Correction” on “VST options” makes no difference to SpitFish …
Not only will effects stop rendering preview after say 5 - 10 applications of the effect, some effects will crash Audacity which never did that before , ( I noticed enabling effect-preview whilst the track is playing can trigger a crash , maybe 1 in 20 occasions ).
That’s a possible explanation : the effect is applying different settings than those on the preview, ( e.g, previous, out-of-date settings ). Having said that, I have SpitFish running in a different DAW , and the applied effects match Audacity : that suggests it’s the Audacity preview which is wrong.
The Lisp DeEsser doesn’t have this problem : preview and applied-effect are essentially the same …
I’ve tried about ten VST effects now on 2.1.0 . All are prone to breaking*, but only the two DeEssers : Spitfish & Antress Modern DeEsser, have a preview which is much different from the applied effect.
SpitFish is not applying the same weak de-ess effect regardless of the settings , the applied effect does change when the settings are changed. Previously I suggested the preview may be applying a double-dose of de-ess , I’ve now compared the preview with a double-dose and the preview has an even stronger de-ess than double application of de-ess. If it is an unintentional iteration of the effect it’s more than twice.
[ *** opening a new instance of Audacity, after an effect has been applied to the first instance and the effect is still selected, can be a cause of the effect-preview to stop working** . When one attempts to use the same effect on the original or new instance, the preview is no longer rendered , or occasionally Audacity crashes ].
Thanks for all the details Trebor.
I presume that this is with Audacity 2.1.1?
Which version of Windows are you using?
At Gale’s suggestion I reverted to 2.1.0 , and I’m using Windows Vista*
I did try 2.1.1.0 and the VST effects were frequently breaking, [failing to render preview], on 2.1.1.0 too
[ * I’ve got another computer with Windows 8 , but I rarely use it, so I’ve yet to install Audacity on that one ].
Before we can put this (“preview effect too strong”) onto bugzilla, we need to know if the problem still occurs on 2.1.1.
You could test this without messing up your working copy of Audacity by downloading the ZIP version of 2.1.1 and creating a “Portable Settings” folder (shout if you need more details about how to do that).
This is GIF animation shows a way of breaking the VST preview on 2-1-0 …
I’ll see if this method also breaks the VST preview on 2-1-1 , and if the SpitFish preview-too-strong problem occurs on 2-1-1 , (watch this space).
The SpitFish de-essing preview being much-stronger than the applied-effect is also true of Audacity 2-1-1-0, see …
Also the method of breaking the VST-preview shown in the GIF animation above also true of 2-1-1-0
I assume this is per your animated GIF, and you are talking about a new window in the same instance of Audacity.
Gale
Can you clarify this, Trebor? Writing out numbered steps is often clearer. Does this mean:
1 Play a track.
2 Open Effect menu
3 Choose a real-time preview effect
4 Crash before the effect GUI appears.
I don’t think the above happens for most effects, even one in 20 times. At least not the ones I have tested with.
Gale
Select a track , choose VST-effect , play that track , check & uncheck the “enable” tickbox on the VST-effect while the track is playing. Occasionally (unpredictably) when checking the “enable” tickbox on VST-effect, when the track is playing, Audacity will crash , ( in my case ).
I can’t find a repeatable way of getting Audacity to crash , but breaking the VST-preview is 100% repeatable for me … To break the preview a particular VST-effect the steps are …
Open 1 track in Audacity, select part of it.
Preview VST-effect , apply VST-effect, uncheck “enable” tickbox on VST-effect, but don’t close VST-effect.
[ previewing not necessary to cause fault , it’s just included here to show preview works at this stage ].
Playback the part of track #1 where VST-effect has been applied. [ this playback seems essential to cause the fault ].
Open a new track in another instance of Audacity , NB: VST-effect is still open in instance #1.
Close the VST-effect ( which is in instance #1 ).
Open the same VST-effect in instance #2 , you’ll now find preview isn’t rendered in track #2 , (preview broken).
Close VST-effect ( which is in instance #2 ).
Re-Open same VST-effect in instance #1 , preview is now not rendered in track #1 either, where it had worked previously.
To recover the preview of that particular VST-effect it is necessary to close all instances of Audacity.
If you close the VST-effect in instance #1 before opening a new instance of Audacity , VST-effect preview works OK in instance #2. Moral of the story : close all VST-effects before opening a new instance of Audacity.
********************** [ “instance of Audacity” = “new Audacity window” ] **********************
[ In my case the above formula will break the preview in the folowing VST-effects :
SpitFish, Antress Modern DeEsser , Anwida DX reverb light, Acon Multiply , DBlue Glitch , DtBlkFx ].
Thank you for your testing, Trebor. 
Is it still your experience that if you were to simply have one track in one Audacity window
then repeat 1) though 3) five or more times that preview would soon fail and you then hear unmodified audio?
Or is it necessary to load presets or open a new Audacity window?
When I have done 1) through 3) repeatedly and very rarely I hear the original audio, pressing Stop then Play restores the preview, or if not, closing and reopening the effect does so.
For me this is something like one time in 200 for each effect I have experienced it in, and some effects do not show this at all. So I never thought it clear enough to put that on Bugzilla.
Gale
It’s my usual-practice to have more than one Audacity window open at once. My “1 in 20” guesstimate of Audacity crashing because of the new real-time preview of VST-effects being enabled would be in the case of having more than one Audacity window open.
So far the only guaranteed way to break a VST-preview requires opening a second Audacity window.
For me the formula above,(which involves opening a second Audacity window), is guaranteed to break the VST-preview. Once broken the fault will persist in that particular VST-effect until Audacity is restarted.
I have had VST-preview fail with only one Audacity window open, but it’s rare, your 1:200 estimate seems about right. Again once the VST-preview is broken a restart of Audacity is required to repair that particular VST-effect ,
( closing then opening the VST-effect doesn’t cure its broken preview ).
We will have to redefine this problem as “De-Esser preview sounds different to the applied-effect” , as
I just tried another DeEsser called “Sibalance” [sic], and the applied-effect is stronger than the preview ,
( whereas with SpitFish the preview is stronger ).
UPDATE: Eureka ! , ( I think ) …
So far the inconsistency between the effect-preview and the applied-effect only occurs on de-essers ,
( 3 out of 4 of them : to the ear LISP de-esser is not effected, but its preview-waveform is not perfectly-identical to that of the applied-effect).
The de-esser effect is dependent of the content of the audio. If the audio being analysed by the plugin, which controls the amount of effect applied, was out-of-sync because of a latency-problem, then the effect-preview and the applied-effect will sound different because they are being defined by different points-in-time on the control-track.
If that is the mechanism for the inconsistency, then any effects which use some parameter from the audio to control their effect could also be inconsistent, e.g. any effects which have threshold-control, (e.g. compressor).