Suggestion: please return a Boolean to indicate LoadGPPreset success load or failure to load.
I tried looking for a Suggestion area for Scripting, but I couldn’t find it?
1 Like
I can imagine that information is not returned by plugins, otherwise I would the result is returned, but the developers probably can answer this assumption.
Yep, I don’t think the plugin is aware. Regardless, GP should return a boolean script.
Why do you need a return of Boolean when you cannot trust the result?
Pointless.
- The call to load a GP Preset is itself asynchronous so it returns immediately regardless of the behavior of the plugin.
- The underlying API that loads the state into the plugin doesn’t return anything either because there’s no way to know how the plugin will handle loading.
1 Like
Let me clarify the necessity for returning a Boolean value in the context of the LoadGPPreset() function:
When executing the instruction “LoadGPPreset(Dexed1, “!!Phils Analog”)” and the corresponding GP preset exists and is successfully loaded, the Log Window will display the message “Dexed: !!Phils Analog loaded.”
Conversely, if the instruction “LoadGPPreset(Dexed1, “Condescending”)” is executed and the GP preset doesn’t exist, the Log Window would show “Dexed: Condescending failed to load.”
While this setup might suffice under certain conditions:
- When actively developing code with the Log Window open to visually inspect the outcome.
- When subsequent actions are not contingent upon the load result.
However, utilizing a Boolean return value provides a clear indication to the program regarding the success or failure of the load operation, enabling further automated processing based on the outcome (true or false). This ensures robustness and reliability in program execution.
I can determine the result myself, but it is a pain in the neck via code. It would be much easier if GP could probide the result.
Well, everything was said here. If I understand well, there is nothing GP can do here.
Several people have already explained that there is no way to know whether the load operation succeeded. That information is not provided by the plugin.
@dhj when the log window indicates a failure to load a preset, that just in reference to the file name not existing?
Gotcha! That misled me into thinking GP knew this, as GP printed the message, not the Plugin. If I were watching the LogWindow, I could see the load failed… but when not developing, I will not have the LogWindow open. So, hence my question to the group.
I wanted to use ‘FileExists()’, but it is documented as unsupported. The last time I tried something like this, it crashed GP, and I lost my Rackspace Script! So, I will not venture into this area again.
You could run some tests using a basic test gig file.
I experimented with that and other experimental techniques about two months ago and wound up crashing GP over and over. LOL! Until the documentation removes the “experimental and unsupported notation”, I will stay away from this area.
Just a note** GP has crashed several times since then and for reasons other than those. It is up to GP to trap crashes. It is not the responsibility or fault of the programmer.
I beleive you can read between the lines (everyone missed my Pointless question). In a nutshell, GP printed the “load failed message”, therefore GP has the capability to tell me. Since, the load is asynchronous, give me a Callback? 
Even when you get a feedback about loading a preset, what would you do within a script?
Good question … In general, I would use the information to determine what path I would take. E.G. In a script I am currently working on, I do the following:
** 1) I let the user choose a GPPreset to load into a specific Dexed. If I am familiar with the preset, I do a LoadGPPreset to load it. **
** 2) Assuming the load went OK, I then proceeed to send the Preset’s 32 patches to Dexed via setting parameter 156 to each patch.**
** 3) 99 times out of a hundred, this process works fine. However, if the Preset did not load, then I have grabbed the wrong patches to provide Dexed. This is not good. lol!**
If I could get a callback after step 1) I would not continue to load irrelevant patches and instead, issue an error message of my own to the end user.
**If @dhj says he can’t do this, then OK, so be it … end of discussion **
On a similar topic, I am so close to rendering my latest creation to the group, an expanded TX816 Rackspace. (Yes, the one that I alluded to a few weeks ago) I am having problems with loading patches to 8 Dexeds in rapid succession from various GPPresets. The problem is not with loading the Presets. I believe I have narrowed it down to an errant timing problem with loading patches to multiple Dexeds. I have tried several techniques … and every time I think I have nailed it, the problem manifests itself once again and does not load one of the 8 Dexeds correclty. The process seems to be faulty when I get to load Dexed #7 and Dexed #8. The problem does not exist with the first 6 Dexeds.
** I do not want to post the problem to the scripting group until I have exhausted every technique to solve it. :)**
Sigh!
All that that message means is that a request was made to the plugin to load a preset and that the preset was not found.
I have changed that message to make it clear that we are only reporting whether the preset was found.
As mentioned earlier several times, the call that actually tells the plugin to load the state does not return any indication of when the plugin has actually completed loading or indeed whether it even loaded anything so there is no way to know when the plugin has actually finished loading even if we did support such a callback.