ExternalFloatingTile with parameter plugin state saving

[ohtravioso]

I'm using the ExternalFloatingTile tutorial example. I have created custom C++ JUCE controls that call setAttribute on a Processor instance with the slider values mapped appropriately.

In my HISE project, I have added controls to the interface so that they'll be part of the preset format. I hide them before exporting so I can use my custom UI.

When using the plugin in Live, changing the parameters affects the sound but their state is not saved correctly with the Ableton Live project. When loading the project again, the last User Preset is loaded correctly, but the parameter changes are gone, and instead match the state of the preset.

I understand this is happening since the HISE interface controls only go in one direction. When you're using the HISE application, and change an interface knob, the parameter you're controlling updates. But when you change that parameter from its HISE front panel, the interface UI does not update. I'm doing the same thing in my code. Changing the parameter directly and not updating the interface UI, so that the state that's saved is that of the user preset I loaded.

So I can think of a few ways forward continuing to use the ExternalFloatingTile test.

1. Use Macros instead of parameters. I believe those are saved with the plugin state, and modifying those from C++ will do what I need, and update the state that the plugin saves with Live. However, there are only 8 slider macros. That's fairly limiting when you're trying to make a custom UI.

2. Modify HISE code so that the scripted interface controls work bi-directionally. They'll listen for updates to the parameters, and modify their state accordingly. That state is then saved with the plugin. So my custom code can continue to modify the parameters directly, and the hidden interface UI will update as well.

3. Modify HISE code so that all the parameters are saved with the plugin state rather than just macros, loaded preset, and scripted controls. Ideally, that's a separate code path from User presets, and it won't affect them.

Which one of these sound best? Is there a way to do this currently that I'm missing?

[Christoph Hart]

Without going too deep into the problem, I think you might be better off with not just using the ExternalFloatingTile, but the complete hise::raw approach. This way you can build up your data model entirely in C++ (basically you get a juce::ValueTree that you can populate yourself without bothering with hacks like hidden script controls).

Have you checked this example project?

https://github.com/christophhart/vcsl_hise/blob/master/AdditionalSourceCode/Raw.h

[ohtravioso]

Thanks Christoph. I'll take a look. So if I go the raw route, I can use the HISE application to build up the project, export it as a snippet to use with raw::builder. However, the UI will need to be built up in C++ along with the preset data model. Then I'll need to hide the controls I don't want exposed to the user in a public facing build, but have them exposed in a sound design build.

[coreyu21]

@ohtravioso so with this method your building if I understand, you will have your own GUI interface with the hise backend system? With this route would it be possible to bypass the headless system build for other application use? Just curious? Thanks

[ohtravioso]

I thought I could use raw::Builder::createFromBase64State with a HISE snippet, but on the scriptnode branch, looks like that feature isn't complete. So once you go to the hise::raw side of things, you need to create the processor chains in code, rather than in the HISE application.

Processor* Builder::createFromBase64State(const String& base64EncodedString, Processor* parent, int chainIndex)
{
	ignoreUnused(parent, chainIndex);

	ValueTree v = ProcessorHelpers::ValueTreeHelpers::getValueTreeFromBase64String(base64EncodedString);

	// TODO
	// Create the processor somehow...

	Processor* p = nullptr;

	p->restoreFromValueTree(v);

	return p;
}

@coreyu21 What is the headless system build? Is that the exporting from the HISE application? Right now, I'm using that system with all of my code in the AdditionalSourceCode folder. If you didn't use that setup and wanted to go more for a from scratch situation, I believe you'd have some work to hook your HISE objects into the audio callback.

[coreyu21]

@ohtravioso there’s a hise build that doesn’t work at the moment but compiles your plugin without the GUI for other application use. I’m not terrific with c++ yet but I was wondering if what you were doing was similar

[ohtravioso]

Ah, no. I’m just doing a standard plugin, but I have more JUCE and C++ experience and wanted full control over the GUI.

[ohtravioso]

@Christoph-Hart I worked off your example, and got a raw version of my sampler setup along with all the attributes I wanted in the preset. I was able to use the ProcessorHelpers::restoreFromBase64String() to get modules in the same state as I had them in the HISE app. All works well.

Question is how to restore the loaded preset for a plugin state. Ableton Live is restoring all the samples maps and parameters correct on loading. But the plugin has no idea what User Preset was loaded.

Is that another attribute I store in the preset? The preset file itself? How do I add it so that the preset API restores the value correct from the value tree?

[Christoph Hart]

@ohtravioso said in ExternalFloatingTile with parameter plugin state saving:

But the plugin has no idea what User Preset was loaded.

You need to store the user preset inside the plugin state and restore it then. Are you using a custom ValueTree for the rest of your data model?

[ohtravioso]

I'm Raw.cpp constructor, I'm calling addToUserPreset with various attributes. Is that way you mean?