Yes, the preset exists and it increases volume by 1 dB. The script works with SF15 build 64 but if I apply later updates it stops doing anything. The script runs, there is no error message but the waveform remains unchanged.

I'm trialing the latest SF16 and it is working better than v15 build 64 with iZotope RX 9. However it still doesn't process my scripts for changing volume. It works with those using built in system presets eg:

using System;
using System.IO;
using System.Windows.Forms;
using SoundForge;public class EntryPoint {
public void Begin(IScriptableApp app) {   app.CurrentFile.DoEffect("Volume",
                            "[Sys] 6 dB Cut (50 %)",   // this must be the name of a Volume preset.
                            app.ActiveWindow.EditRegion,
                            EffectOptions.EffectOnly);
   app.CurrentFile.WaitForDoneOrCancel();
}public void FromSoundForge(IScriptableApp app) {
   ForgeApp = app; //execution begins here
   app.SetStatusText(String.Format("Script '{0}' is running.", Script.Name));
   Begin(app);
   app.SetStatusText(String.Format("Script '{0}' is done.", Script.Name));
}
public static IScriptableApp ForgeApp = null;
} //EntryPoint

But for presets I've named myself nothing happens. The scripts compile OK and run without error but just don't change the volume. This problem began with SF15 later builds.

I really need a quick way to change volume. Can anyone suggest changes to my code or alternative code that will allow changes to volume by 1 to 6 decibels? Thanks.

• I deleted the custom preset and I changed EffectOptions.EffectOnly to EffectOptions.DialogFirst.
• Then I ran the script. The Volume-Dialog opened. I created the preset and saved it under a name.
• Then I canceled the process.
• Then I changed EffectOptions.DialogFirst back to EffectOptions.EffectOnly.

It now works every time without problems. Even after restarting the application.

Brilliant SP! What ever gave you the idea of recreating the scripts using DialogFirst? Initially I had some trouble as SF wouldn't let me delete the existing presets. They would reappear after I reopened the volume dialogue. So I just copied and pasted the preset names from the script and saved them afresh. I wasn't prompted to rename them so I suspect the whole dialogue is flaky. I've opened and closed Sound Forge and so far so good. The scripts work. Thank you so much.

I am experiencing the same problem, with some differences. My script, which still works in SFG13, tries to use a graphic-fade preset. Whether I use one I made myself or a factory preset, the script always applies a linear fade-in instead of the preset I request, as though I had instead used the <PROCESS - FADE - IN> menu option. It does the same if I enter a bogus preset name, which makes me think it isn't even looking at the name. Maybe it is defaulting to a linear fade-in when it sees no name? Has the way the interpreter handles arguments changed?

The work-around SP described above more-or-less works for me, although I notice the preset I save does not show up in the preset list afterwards. Also, when the script asks for a dialogue first, the drop-down list does *not* include other presets I have made. I guess it must be storing a second list elsewhere? Seems like this is the problem: User presets are stored in one place, and the scripts are looking at a different copy of the list.

@Kurt-Larson I think most effects in Sound Forge are DirectX plugins.

If I remember it correctly the user presets were stored in the Windows registry under HKEY_USERS\*long-ID-number*\DirectShow\Presets and HKEY_CURRENT_USER\SOFTWARE\DirectShow\Presets

Thanks SP, but... hm. I'm not sure how this information connects...

If you just mean it is a place to check for info, sure. But the problem seems to be that SFG16 is maintaining two separate sets of presets.