Hi. Changelog for 5.0.40 states a function to load Plugin Presets has been added to SDK.
However over on Github repo I cannot find anything about this.
Most recent release is 4.8.
On beta-sdk-v60 there’s an sdk build that is at least compatible with GP5.
However this one doesn’t include the newest additions which I’m looking for either.
Thanks,
Jannik
@rank13 not sure if you can handle this but I appreciate if you can forward this to the dev who’s responsible for the SDK releases.
I can confirm that these don’t appear to be in the GitHub SDK.
I think @dhj or @simon or @Dadi might have some insight on getting the github SDK updated.
I have not looked at the github version nor really studied how things were changed.
The latest version that we created can be downloaded from this link but it’s not in the same format as what was available on github
I’ve messaged a few of you… I may consider taking on keeping the SDK updated on GitHub. I’ll copy in a few more of us extension devs to the conversation.
What is this SDK
What can we do with that!!!?
The SDK allows third parties to develop extensions for Gig Performer
@dhj I checked the zipped SDK you linked to. It doesn’t include the improvement that was listed in the changelog either. No clue of an implementation to call loadGPPreset.
Assuming the changelog can be trusted there has to exist an updated SDK version somewhere. Can you find out who’s been working on it?
@dhj / @simon / @Dadi / @rank13
Can someone please provide the SDK as described in the changelog.
I’m again stuck with implementing the needed functionality and unable to complete my work.
Has it been lost? Does it exist? Has it been added to the changelog by accident?
Sorry - that was the wrong link (corrected above)
@dhj have you tested if the loadGPPreset SDK function actually works?
It doesn’t do anything for me, always returns false.
Other SDK functions like setPluginParameter work fine, and my logs show the plugin handle is being found.
I tried to pass the preset name as one would do when calling loadGPPreset in script.
Then I also tried to append the preset file extension as well as passing in an absolute path to the preset file.
Anything special that must be taken care of to make it work? 
Are you calling it from the message thread?
Ah, I didn’t look into what threads GP is running by now.
Guessing the GPScript logic runs in a separate thread?
this would explain it then. (called loadGPPreset from within a GPScript callback).
Does the SDK provide access to any useful functionality for handling its different threads?
Or should I implement a custom scheduler/queue system?
(I imagine this must be quite similar to how the “native” GPScript-callback loadGPPreset works, cause it runs in the script thread too)
Edit: Found an old thread shedding some light on GPs threads as well as what the SDK aims to provide and what not. What is the best way to use a timer? So I’ll do some investigation and maybe port the extension to work with JUCE.
GPScript has nothing to do with the SDK
GP Script is intended for people who do not have a developer background and so how it executes is mostly hidden. For example, GP Script calls the LoadGPPreset function though the main thread so a GP Script programmer doesn’t have to deal with such things.
On the other hand, the SDK assumes expertise with C/C++ (or any language that can use C headers) and so doesn’t try to hide stuff from the developer. That said, the documentation for that function clear states how it needs to be called.
I should also add that there are no guarantees as to which thread will invoke a function in the SDK. There are numerous threads for handling GP Script, MIDI messages, OSC messages, and various other things. Functions in the SDK can be invoked by any of those as well as by the main GUI thread.
Alright, that’s what I guessed, just chose different words to describe.
Can I rely on the extension always being instanced/created in the main thread?
Think I’m gonna try my luck with JUCE’s MessageManager system.
Hopefully this won’t conflict with however GP handles main thread scheduling by itself.
I’ve used an existing branch for the sdk on github, and added the new loadGPPreset function. I then created a test extension that attempted to load a GP Preset for a plugin (KeysOfThe70s) where the preset name matched the variation name. Everything worked perfectly!
thanks for confirming! Think I got a good clue of what has to change to make it work now.
Alright, if ever some other extension dev stumbles upon this:
Basing your extension on JUCE is a smart decision if you plan for something more complex and need to handle threads correctly.
After setting up JUCE, it’s real simple to execute functionality in main/message thread:
juce::MessageManager::getInstance()->callAsync([]() {
bool success = loadGPPreset("pluginHandle", "presetName", isGlobal));
});
Yes, using JUCE for this has been recommended in the past - it buys you a lot