Engine.loadUserPreset for expansions?

[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?