Issue with Sound Forge Pro 16 and scripting

Unsounded wrote on 5/15/2022, 5:15 AM

I was hopeful that the new version of Sound Forge would have overcome the bug that appeared in version 15 after build 64. Basically various scripts that compile correctly do nothing when they are run. For example, here is a script I have been using for years:

using System;
using System.IO;
using System.Windows.Forms;
using SoundForge;public class EntryPoint {
public void Begin(IScriptableApp app) {   app.CurrentFile.DoEffect("Volume",
                            "1 dB Boost (112.20 %)",   // 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;
}

This works with SF15 build 64 but not with SF16. Nothing happens when the script is run. I'd like to upgrade but I'm stuck as scripts I rely on don't work with the new version. So my feedback is please improve scripting. Thanks.

Comments

SP. wrote on 5/15/2022, 8:46 AM

@Unsounded Does this preset "1 dB Boost (112.20 %)" exist in your Sound Forge installation? What are the settings of this preset?

Unsounded wrote on 5/15/2022, 7:00 PM

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.

Unsounded wrote on 9/2/2022, 2:37 AM

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.

SP. wrote on 9/2/2022, 3:24 AM

@Unsounded I tried it out for myself in Sound Forge Pro 15 Build 161 and yes, your are correct. It doesn't work in later versions of Sound Forge. This has to be some kind of bug. So I made the following changes.

  • 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.

Unsounded wrote on 9/3/2022, 7:04 PM
  • 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.

Kurt-Larson wrote on 11/22/2022, 1:24 PM

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.

SP. wrote on 11/22/2022, 4:09 PM

@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

Kurt-Larson wrote on 11/22/2022, 4:16 PM

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.

SP. wrote on 11/22/2022, 4:32 PM

@Kurt-Larson If you search for your custom preset name and it's not in the registry it could be a bug (and maybe the cause of our scripting problem) or the developers changed something in the preset system, like you already suspected, and broke functionality. I don't know if DirectX plugins presets must be stored in the registry.