Sound Forge 4.5h and DirectX plug-in parameter saving -Sound Forge - PC

Subject:Sound Forge 4.5h and DirectX plug-in parameter saving Posted by: habaneroburger Date:12/23/2002 11:58:08 PM I'm using an older version of Sound Forge, 4.5h (yeah, yeah, I know, but it's been a workhorse for me and I haven't had the need to update), to test some DirectX plug-ins that I've been developing. I've noticed some strange behavior with respect to saving parameter values (which may or may not be my bug, but in any event SF doesn't seem very robust in some of its handling of plug-ins), and I'm wondering if there's any chance somebody can shed some light on it or give me a good workaround. The problem, in a nutshell, is that while SF normally saves the parameter values for any plug-in you run on a sound file and repopulates it with those values next time you bring it up, it sometimes gets in a state where it won't save parameter values for one or more of my plug-ins, and instead uses the default parameter values each time, and no amount of thrashing around seems to help. When the plug-in runs, it uses the correct parameters that I've entered into the dialog; they just don't get repopulated next time. When I debug it, I see that Sound Forge calls my plug-ins save parameter values when it first brings up the plug-in's property page, and it normally follows that by a call to load when things are working well, but when they aren't, load is never called. I don't have enough information (or debugging symbols) to be able to see what SF is doing differently in the two cases. With load never being called, my plug-in populates itself with the defaults for parameters, consistent with the behavior I see. If it's any help, I'm using Cakewalk's plug-in SDK for DirectX plug-ins, with their sample code. If you're really curious, the code for one of my plug-ins is at http://www.pacificsoundcraft.com/software/directx/noisegate As a workaround, I've tried blowing away the registry keys for SF's DirectX cache (HKEY_LOCAL_MACHINE\SOFTWARE\Sonic Foundry\DXCache and ...\Sound Forge\4.5, as well as its saved setting file, frgqz.SFP in the program directory, but it doesn't clear it up -- if I do that, Sound Forge will find the settings for the last time the plug-in was run (where does it get them? I can't find out) and will use those for the next invocation, but subsequent invocations have the same problem. I've seen this problem a couple times. Once, it was my bug, where I forgot to set the modified flag in the OLEPropertyPage for my control, and SF saw no need to save settings; fixing that bug solved the problem. The next time it happened, that wasn't the problem, I wasn't able to figure out what was going on. Changing the GUID for my plug-in and its property page made it work, but now it's happening again on the plug-in I'm developing as well as one that worked before and hasn't been changed. Only the plug-ins I've written have this problem. Commercial plug-ins save their parameters just fine. It's quite possibly a bug on my part, or some flakiness that SF doesn't like (e.g. Sonar has many problems, but seems to be able to handle DirectX parameter saving), but I don't know what it is. Is there a chance somebody's reading this that may have an idea what's going on, and can either give me tips on what I'm doing wrong, give me a workaround to kick SF in the tail if it's a SF problem, or even confirm that things should work differently in a later version of SF? I'll upgrade if I know it will solve the problem, but won't if I'm not sure.
Subject:RE: Sound Forge 4.5h and DirectX plug-in parameter saving Reply by: habaneroburger Date:12/25/2002 7:55:24 PM Well, after spending a considerable amount of time tracing through the disassembly of what leads up to Sound Forge calling my plug-in's parameter save/load code, I think I have the solution. I'll post it here just in case some future person Googles this page and is looking for a solution to the same problem. First off: it appears that Sound Forge 4.5h is substantially a 16-bit application. Good job, guys. Hopefully subsequent versions have joined the rest of us in the 32-bit revolution, which happened five years before this program was released. Anyhow, the problem seems to be that I wasn't getting all of the old saved data for the plug-in flushed when I tossed the frgqz.SFP file and the DXCache and SoundForge\4.5 keys in the registry. There are a couple things: the default settings are saved in the FORGE.INI file in the Windows directory (which is where it finds the old default values after I blow away the other files; I was wondering that before). It also appears to store a copy in the registry under HKEY_CURRENT_USER\Software\DirectShow\Presets\<Plug-in GUID>. This key is related to the RegSynced parameter in frgqz.SFP file, though I haven't looked at the exact relationship of that parameter to the .INI file and the registry key. I just found out that if you blow away the relevant DirectShow\Presets\GUID registry key, all returns to normal. At that point I was happy to have a solution and ended my investigation. I think what was triggering this is that during the development of my plug-in, I'll sometimes change the saved parameter format, adding or removing parameters, or the like. I think that maybe it's causing incompatibilities with the FORGE.INI version and the registry version, or some such, and Sound Forge is getting confused and refusing to deal properly with life after that. It's kind of as I suspected -- something I'm doing that's a little weird, combined with a lack of complete robustness on Sound Forge's part.

I'm using an older version of Sound Forge, 4.5h (yeah, yeah, I know, but it's been a workhorse for me and I haven't had the need to update), to test some DirectX plug-ins that I've been developing. I've noticed some strange behavior with respect to saving parameter values (which may or may not be my bug, but in any event SF doesn't seem very robust in some of its handling of plug-ins), and I'm wondering if there's any chance somebody can shed some light on it or give me a good workaround.

The problem, in a nutshell, is that while SF normally saves the parameter values for any plug-in you run on a sound file and repopulates it with those values next time you bring it up, it sometimes gets in a state where it won't save parameter values for one or more of my plug-ins, and instead uses the default parameter values each time, and no amount of thrashing around seems to help. When the plug-in runs, it uses the correct parameters that I've entered into the dialog; they just don't get repopulated next time.

When I debug it, I see that Sound Forge calls my plug-ins *save* parameter values when it first brings up the plug-in's property page, and it normally follows that by a call to *load* when things are working well, but when they aren't, load is never called. I don't have enough information (or debugging symbols) to be able to see what SF is doing differently in the two cases. With load never being called, my plug-in populates itself with the defaults for parameters, consistent with the behavior I see.

If it's any help, I'm using Cakewalk's plug-in SDK for DirectX plug-ins, with their sample code. If you're really curious, the code for one of my plug-ins is at http://www.pacificsoundcraft.com/software/directx/noisegate

As a workaround, I've tried blowing away the registry keys for SF's DirectX cache (HKEY_LOCAL_MACHINE\SOFTWARE\Sonic Foundry\DXCache and ...\Sound Forge\4.5, as well as its saved setting file, frgqz.SFP in the program directory, but it doesn't clear it up -- if I do that, Sound Forge will find the settings for the last time the plug-in was run (where does it get them? I can't find out) and will use those for the next invocation, but subsequent invocations have the same problem.

I've seen this problem a couple times. Once, it was my bug, where I forgot to set the modified flag in the OLEPropertyPage for my control, and SF saw no need to save settings; fixing that bug solved the problem. The next time it happened, that wasn't the problem, I wasn't able to figure out what was going on. Changing the GUID for my plug-in and its property page made it work, but now it's happening again on the plug-in I'm developing as well as one that worked before and hasn't been changed.

Only the plug-ins I've written have this problem. Commercial plug-ins save their parameters just fine. It's quite possibly a bug on my part, or some flakiness that SF doesn't like (e.g. Sonar has many problems, but seems to be able to handle DirectX parameter saving), but I don't know what it is.

Is there a chance somebody's reading this that may have an idea what's going on, and can either give me tips on what I'm doing wrong, give me a workaround to kick SF in the tail if it's a SF problem, or even confirm that things should work differently in a later version of SF? I'll upgrade if I know it will solve the problem, but won't if I'm not sure.