@rzrsharpeprod As Dave said. The mouse CB can be tricky sometimes because the order of event you need is often very project dependent. I use it a lot, and I still have to try/fail/succeed until I have no hair anymore and the light can shine through the skull directly, and boom I get it...

what can be really helpful is to keep a Console.print(trace(event)); a the top of the CB to understand better the order of events

@d-healey I will, I just discovered an error I've made that might be an happy accident... Need to test further...

@d-healey It seems I manage to solve it, using your code plus a safety that "protects" the protected parameters CB, and keeping the initial preset loading.

Not sure why the bypass button were always initialising to 0 without the preset load though...

@d-healey nope, I should have said only for preset loading, not DAW

This preset thing drives me crazy...

it work in a minimal example, but same code in the project won't work despite I checked everything I could...

And another strange thing arose, now I removed the initial preset loading, my bypass button is deactivated when a new instance is inserted in DAW. But it initialises normally in Hise, its default value is obviously 1, and it's not set anywhere in code. The project is well saved before export and build folder cleaned... Turning around and around with this lol

@ustk Alright so after removing the initial preset I still have the same behaviour (protected with presets but not with DAW load)

I'll try again tomorrow with a fresh mind... Thanks, Dave!

@d-healey Oh what what what?
Seems not to be an ideal behaviour though...

Starting again and report

@d-healey said in saveInPreset vs custom prefFile vs what?:

Does Live use VST3?

Yes, and I tried with AU too
I'm building again in case I've made a mistake

@d-healey In fact the logic is not hard, it should never change the parameters, whether it’s a preset change or DAW session load.
So since in both cases the pre and post CB are called, it should always protect the parameters. But it’s not happening for some reasons…

Have you tried to build and test with a DAW?

Oh you tried already…
Yes I have set a default preset

@d-healey Thanks Dave! I thought this was it. It holds for DAW session recall but not for preset change strangely, despite it works in Hise. Tried with ProTools and Live

@Chazrox Yeah AFs in Hise can be fetched from anywhere, AudioPlayer, Scriptnode, Sampler, etc...
The methods can differ but I imagine there are some examples in the doc and the snippet browser

@Chazrox Scriptnode is not necessary if you don't go real time, so Chris's example has already (almost) what you need.
Ok you want to display an FFT, but from what source? sampler? internal AF? user drag/drop AF?
You must start here, then it'll only be a matter of getting a reference of that AF and feed the buffer.

Here's a starting point

inline function onButton1Control(component, value)
{
	if (value)
	{
		FileSystem.browse(FileSystem.Desktop, false, "", function(result)
		{
			arrayOfBuffers = result.loadAsAudioFile();
			
			// do fft with this array of buffers
		});
	}
};

Content.getComponent("Button1").setControlCallback(onButton1Control);

@d-healey Lovely

What ever I try, saveInPreset enabled/disabled, use or don't use isInternalPresetLoad, I can't get this to work.
It either make the component to persist on preset load but not on DAW init, or the opposite, or nothing...

I need to make the components persistent for both cases, preset load AND DAW recall.

my base structure is:

// will hold some parameters that need to be protected when a preset is loaded or the DAW loads the session
const var protectedControls 		= [oversamplingBtn, oversamplingKnb];
const var protectedControlStates 	= [];


//! Pre load CB
uph.setPreCallback(function(presetFile)
{
	// Protect the controls we don't want to see changing during user preset load AND DAW session load
	if (this.isInternalPresetLoad())
	{
		for (i=0; i<protectedControls.length; i++)
			protectedControlStates[i] = protectedControls[i].getValue();
	}
});


//! Post load CB
uph.setPostCallback(function(presetFile)
{
	// Protect the controls we don't want to see changing during user preset load AND DAW session load
	if (this.isInternalPresetLoad())
	{
		for (i=0; i<protectedControls.length; i++)
		{
			if (isDefined(protectedControlStates[i]))
			{
				protectedControls[i].setValue(protectedControlStates[i]);
				protectedControls[i].changed();
			}
		}
	}
});

I also tried to "pre-save" the component values in protectedControlStates from their respective CBs.

If anyone has a clue or even better, a snippet, that would be amazing

@Christoph-Hart That is what I understood too... Was nice indeed

@It_Used Because your Y position for the gradient and rectangle is fixed. But you want it to move so it follows the height (bottom) of the black key.
Instead of going from the top, do it from the bottom obj.area[3]

// Set key bottom colour.
g.setGradientFill([Colours.withAlpha(0x252525, 100), obj.area[0], obj.area[3] - 10, Colours.withAlpha(0x0D0D0D, 100), obj.area[0], obj.area[3]]); // [Colour1, x, y, Colour2, x, y].
 		
// Draw key bottom bounds.
g.fillRoundedRectangle([obj.area[0] + 2, obj.area[3] - 10, obj.area[2] - 4, 10], {CornerSize: 2, Rounded:[1, 1, 1, 1]}); // [x, y, w, h].

Can we simulate a DAW session loading within Hise to test isInternalPresetLoad()?
I thought yes, but I've probably hallucinated...
Compiling and codesigning for this kind of test can be cumbersome

@Christoph-Hart said in g.dropShadowFromPath got funky on macOS between May 30 and July 02:

p.scaleToFit(a.getX(), a.getY(), a.getWidth(), a.getHeight(), false);

Confirmed, that's the one

@Chazrox If it's not real time, then the FFT in the API list should do it. Otherwise it needs C++ and a global cable to send the data back to the interface

@aaronventure said in g.dropShadowFromPath got funky on macOS between May 30 and July 02:

I can't make any sense of this, I didn't use getLocalBounds, I use calculated dimensions based on keyboard parameters... How are you getting the correct positions for the shadow?

Since the path is made at the right dimension, its bounds are just the area I need.
Effectively it doesn't make any sense because in the end the area is the same as the previous one. I think the issue comes from a conversion behind the scene, but why...