UI Zoom Factor

[ustk]

@Christoph-Hart gorgeous, I’ll give it a go sometimes tomorrow

[ulrik]

@Christoph-Hart Beautiful, thank you!

[ulrik]

@ustk Yezzz...great! You'll get a bear as well

[Dan Korneff]

[Natan]

@Christoph-Hart said in UI Zoom Factor:

message to the UI to resize).

Oh Wow, Thank You
Any Examples is much appreciated

[ustk]

@Christoph-Hart So I've made the API, but it is of course non-dynamic, as the plugin has to be closed and reopened like for the norm zoom factor setting.
So the question is, is it easily doable to have it resized in real-time using the same API, or is it a totally different approach?

[Christoph Hart]

Did you use sendNotification? It's basically the same thing that the combobox of the settings dialogue does.

[ustk]

@Christoph-Hart Yes

void ScriptingApi::Engine::setZoomLevel(double scaleFactor)
{
	auto mc = getScriptProcessor()->getMainController_();
	AudioProcessorDriver* driver = dynamic_cast<AudioProcessorDriver*>(mc);

	driver->setGlobalScaleFactor(scaleFactor, sendNotification);
}

or

void ScriptingApi::Engine::setZoomLevel(double scaleFactor)
{
	auto mc = getScriptProcessor()->getMainController_();
	dynamic_cast<AudioProcessorDriver*>(mc)->setGlobalScaleFactor(scaleFactor, sendNotification);
}

which is the same thing

[ustk]

@Christoph-Hart I think we need this

#if USE_FRONTEND

	auto fpe = mc->findParentComponentOfClass<FrontendProcessorEditor>();

	if (fpe != nullptr)
	{
		fpe->setGlobalScaleFactor((float)scaleFactor);
	}
#endif

then findParentComponentOfClass must be adapted but I don't know how...

What's the difference between getScriptProcessor()->getMainController_(); and getProcessor()->getMainController();?
Both are working...

[Christoph Hart]

They are both the same (and one just calls the other method with a dynamic cast).

Ah I see the problem (not sure how I could have missed that when I wrote my last answer). The editor window is not registered to the ScaleFactorListener system (which is weird because the system is made exactly for this purpose). I think I have to take it from here and clean up my own mess :)

[ustk]

@Christoph-Hart Nice, I've just seen you implemented it yourself ;)

You also corrected the macOS compilation, but I still have the same issue when compiling:

[Christoph Hart]

Yeah, I accidentally committed this to the SNEX branch, it was meant to go to the Scriptnode branch, but I'll transfer it real quick.

[ustk]

This post is deleted!

[d.healey]

@ustk Think it's possible to add the same kind of function for the Streaming Mode?

[ustk]

@d-healey I can't tell but I can have a look…

[ustk]

@d-healey @Christoph-Hart I've done it and it seems to work... But I'm not against an input from Christoph before pushing :)

void ScriptingApi::Engine::setDiskMode(int mode)
{
	auto mc = dynamic_cast<MainController*>(getScriptProcessor()->getMainController_());

	AudioProcessorDriver* driver = dynamic_cast<AudioProcessorDriver*>(mc);

	driver->diskMode = mode;
	
	mc->getSampleManager().setDiskMode((MainController::SampleManager::DiskMode)mode);
}

So mode should be 1 for fast and 2 for slow due to the original combobox offset.
Do you prefer a 0 based value? (0-fast 1-slow)

[d.healey]

@ustk

Do you prefer a 0 based value? (0-fast 1-slow)

Thanks @ustk! Yes I prefer 0 based. HISE combo box values mess with the system :p

[Christoph Hart]

Yes zero is better, this represents the actual number in the XML file:

<?xml version="1.0" encoding="UTF-8"?>

<GLOBAL_SETTINGS DISK_MODE="0" SCALE_FACTOR="1.0" VOICE_AMOUNT_MULTIPLIER="2"
                 GLOBAL_BPM="-1.0" MIDI_CHANNELS="1" SAMPLES_FOUND="1" OPEN_GL="0"/>

[ustk]

@Christoph-Hart @d-healey It was already 0-1 based I was just talking nonsense :crazy_face:
That's it, pushed and working...