Engine.loadUserPreset for expansions?

[bendurso]

@d-healey Because the searchbar don't work on expansions, and the button bounds "Add, Rename, Delete" can't be increased. Mainly for these two things.

[bendurso]

@Christoph-Hart Does Engine.loadUserPreset works for expansion presets? How should be the proper way to reference the path? Thanks :)

[d.healey]

@bendurso Did you try using {EXP::Auralis}Category 3/Native Preset.preset directly?

[bendurso]

@d-healey Yeap, doesnt work.

When you use a string path it adds "Plugin/User Presets" + the string path. (that's the error log of the console)

like this:
Plugin/User Presets/{EXP::Auralis}Category 3/Native Preset.preset

[bendurso]

@bendurso The only way it doesnt return an error is if I use a object full path to the preset with FileSystem.fromAboslutePath(), it starts loading a bit and Hise crashes.

[d.healey]

@bendurso said in Engine.loadUserPreset for expansions?:

When you use a string path it adds "Plugin/User Presets" + the string path.

You mean Engine.loadUserPreset("{EXP::Auralis}Category 3/Native Preset.preset");?

[bendurso]

@d-healey Yeap, if you use that, the console returns:

User preset /Volumes/Ben/Hise Projects/Raizes Player/UserPresets/{EXP::Auralis}Category 3/Native Preset.preset doesn't exist

It directly searches inside the main plugin User Presets folder, so it's impossible to make it work.

[d.healey]

@bendurso You said using a File object causes a crash. What about instead of using fromAbsolutePath you piece the path together, something like this:

local rootFolder = Expansion.getRootFolder(); // I can't remember the proper function name
local preset = rootFolder.createDirectory("UserPresets").getChildFile("myPreset.preset");

[bendurso]

@d-healey I had also previously tried building the entire path that way and it doesn't work either :( I mean, it doesn't throw an error but it crashes.

I just tried in the compiled plugin, and it also crashes :(

[d.healey]

@bendurso I'll do some tests

[d.healey]

@bendurso Ok it's an issue with the loadUserPreset function

This is what it looks like in the source

File userPresetRoot = FrontendHandler::getUserPresetDirectory();

userPresetToLoad = userPresetRoot.getChildFile(file.toString());

As you can see, no matter what we pass in (file) it's always going to try and load it from the userPresetRoot which is the project's user presets folder not the expansion's. I'll see if I can implement a fix.

[d.healey]

I've played around with it but it would take me quite a while to find a solution and I don't have the time at the moment to really dig into it.

Either we need to modify the loadUserPreset function to use the expansion's preset folder when the filename is an expansion wildcard reference. Or we need a separate Expansion.loadUserPreset() function. My preference would be for the former.

[bendurso]

@d-healey Nice, maybe I could post a feature request and see if anyone else is interested? I find it strange that no one has found this before.

[d.healey]

@bendurso said in Engine.loadUserPreset for expansions?:

I find it strange that no one has found this before.

I don't think many people are using expansions.

[bendurso]

@d-healey I was checking the source code, and actually I think it should work an expansion preset with the absolute path.

void ScriptingApi::Engine::loadUserPreset(var file)
{
	auto name = ScriptingObjects::ScriptFile::getFileNameFromFile(file);

	File userPresetToLoad;

	if (File::isAbsolutePath(name))
	{
		userPresetToLoad = File(name);
	}
	else
	{
#if USE_BACKEND
		File userPresetRoot = GET_PROJECT_HANDLER(getProcessor()).getSubDirectory(ProjectHandler::SubDirectories::UserPresets);
#else
		File userPresetRoot = FrontendHandler::getUserPresetDirectory();
#endif

Because the code you mentioned (the "else" part) only runs if it's not an absolute path.

And it actually loads the preset with absolute path, but I don't know why it crashes immediately. It doesn't crash with a non-expansion preset, so the problem might be somewhere else.

[d.healey]

@bendurso Ah good work, looks like it must be this function that's at fault then

[bendurso]

@d-healey Oh. Maybe @Christoph-Hart could take a look to this?