AAX plugin doesn't initiate default slider values when loaded in Pro Tools

[gorangrooves]

@Christoph-Hart Thanks very much. I will be sure to bring this up with AVID. If it is affecting JUCE, then this is affecting a lot of developers and is not HISE-specific. It took me an hour just to get started with the "industry standard" Pro Tools. I felt like I was debugging their software and not there to test mine. Goodness fuck.

I will report back on how this hack works.

[ps]

@Christoph-Hart the problem is that you really have to find a specific custom trigger value for your plugin that a user will never save as preset / store the session with or that will most likely never be set when the user is duplicating the plugin in the daw. this is why I suggested main gain out because why would you store a session with main out put to -100.
That's something I forgot to mention you have to use the lowest value of the slider range because that is what protools will set it to on init.
So If you have set master gain range -70/ 0 you have to call If MasterGain.get Value()== -70 - load preset that you want as init.
you could use a hidden dummy slider of course as well bit it will show up as plugin parameter and might lead to confusion.

[orange]

@ps @gorangrooves

I've checked again the the plugins that are exported on June 2022 (develop branch). All of the sliders are working without any issues.

I haven't built plugins with the current commit, but if this issue still persists, then the root cause might be some commits after that date.

But I think setting the gain range to -70 or setting a timer object to call the settings won't be more than a temporary solution and won't be healthy.

Since the time hasn't been passed so much from June, it could be easier to find the root cause.

[Lindon]

@Christoph-Hart said in AAX plugin doesn't initiate default slider values when loaded in Pro Tools:

So a "generic" script would look like this:

const var ProtoolsParameterFixer = Engine.createTimerObject();

ProtoolsParameterFixer.setTimerCallback(function()
{
	for(c in Content.getAllComponents(".*"))
	{
		if(c.get("isPluginParameter"))
		{
			c.setValue(c.get("defaultValue"));
			c.changed();
		}
	}
	
	this.stopTimer();
});

ProtoolsParameterFixer.startTimer(600);

@gorangrooves if this solves the problem I could add this as native C++ function, then it will only be called when loaded as AAX plugin and I'll try to not make a educated guess how long it will take, but somehow call it after the plugin initialisation. Still not sure why the default values aren't used by Protools, the code in HISE looks OK.

-- Im confused - wont this just reset every component to its default value everytime you start the plugin?

So I load it into PFools for the first time and it does this = good, I change some things and save my session, then I reopen the session only to lose all the changes I made to components = bad?

-- or do I not really understand(likely)?

[orange]

@Lindon Yes I think it will override the saved PT session settings, so PT daw session can't be saved.

[Lindon]

@orange said in AAX plugin doesn't initiate default slider values when loaded in Pro Tools:

@Lindon Yes I think it will override the saved PT session settings, so PT daw session can't be saved.

hmm, thats not a solution then is it...sadly.

[Christoph Hart]

I think the secret ingredient that I forgot to make this work with restoring projects is like @ps suggested: use a bogus value that no sane user will ever use for a particular parameter, then restore if that value is met.

Is it hacky? Sure. Is it the appropriate solution to the problem. Hell yes.

[Lindon]

@Christoph-Hart said in AAX plugin doesn't initiate default slider values when loaded in Pro Tools:

I think the secret ingredient that I forgot to make this work with restoring projects is like @ps suggested: use a bogus value that no sane user will ever use for a particular parameter, then restore if that value is met.

Is it hacky? Sure. Is it the appropriate solution to the problem. Hell yes.

I think I'm going to prefer a config file read/write:

if the file is not there then do this thing, and write the file...

in fact what (I assume) we all want is ProTools to load our "default" preset, does it not do this also?

[orange]

@Lindon said in AAX plugin doesn't initiate default slider values when loaded in Pro Tools:

I think I'm going to prefer a config file read/write:

if the file is not there then do this thing, and write the file...

Let's say the user has 50 sessions with your plugins (and on each session there are a couple of plugins), so the plugin will save each setting for each plugin instance?

Why try harder? All of these sliders were working till a couple of months ago, I think the reason will be (needs to be) fixed.

[d.healey]

@orange Can you narrow down to which commit?

[Lindon]

@orange well I have a user with AAX plugins from over a year ago -- and these are not working either - so its not a recent problem.

[Lindon]

@Lindon said in AAX plugin doesn't initiate default slider values when loaded in Pro Tools:

I think I'm going to prefer a config file read/write:

Actually I'm pretty sure none of these approaches work if we think about it for a minute....

[orange]

@d-healey said in AAX plugin doesn't initiate default slider values when loaded in Pro Tools:

@orange Can you narrow down to which commit?

@Lindon said in AAX plugin doesn't initiate default slider values when loaded in Pro Tools:

@orange well I have a user with AAX plugins from over a year ago -- and these are not working either - so its not a recent problem.

No it is a recent issue (I haven't compiled the current commit yet). The button issue is there for years. But sliders were working.

The exported plugins on June (develop branch) are working. You can try these yourself, I checked yesterday.

[gorangrooves]

Ideally, PT should load the default values. If we can't have the ideal, we need to settle for the next best solution, at least until the ideal is achievable.

Looking at Christoph's script and comparing it to my sliders, this is what I notice:
The default values for the sliders do not match the initial values of the sliders. Some sliders may be at 0.34, while the default value is set to 0.8. Actually, most sliders seem to have this value of 0.8. So restoring the defaultValue would not solve the problem unless we go and manually enter default values for all sliders to match what they are on the initial load normally. This would be very time-consuming.

So, I guess recalling the default preset would be a more practical solution, as @ps suggested. Of course, this means that you must have the presets implemented in your plugins.

[gorangrooves]

So, to get around the defaultValue not being equal to the actual value, I tweaked a portion of Christoph's script which should be run once when final settings are made, then commented out before compiling.

//Set defaultValue of all components, which are plugin parameters, to their current values
// IMPORTANT: Comment this out before the plugin compiling

for(c in Content.getAllComponents(".*"))
	{
		if(c.get("isPluginParameter"))
		{
			c.set("defaultValue", c.getValue());
		}
	}

Now that the default values are correct, we can proceed with the combination of Christoph's and ps scripts.

[gorangrooves]

Alright, guys, please check if this looks OK, using @Christoph-Hart 's script and combined with @ps strategy.

//-------Pro Tools initial settings fix

const var ProtoolsParameterFixer = Engine.createTimerObject();
const var DrumsSlider = Content.getComponent("DrumsSlider"); // This should not be 0 by default


ProtoolsParameterFixer.setTimerCallback(function()
{
	for(c in Content.getAllComponents(".*"))
		{
			if(DrumsSlider.getValue() == 0 && c.get("isPluginParameter"))
			{
				c.setValue(c.get("defaultValue"));
				c.changed();
			}
		}
	this.stopTimer();
});

ProtoolsParameterFixer.startTimer(600);

[orange]

@gorangrooves Does this AAX issue happens in all operating systems? Windows, macOS intel & M1?

[gorangrooves]

@orange I've only tested it with Windows, and the above script did not do the trick, unfortunately. Maybe I didn't write it properly. I'll have to revise it.

[gorangrooves]

There is actually a build error. The plugin didn't compile. I was testing my previous AAX plugin version. I will be posting the compiling error info as soon as I test whether VSTi compiling works.

[gorangrooves]

Guys, I am happy to report that the above script works well and restores the default values in Pro Tools seamlessly. This should do the trick until a "proper" fix is figured out. It certainly beats having customers load the plugin for the first time that doesn't make any sound with no indication of why.

I am yet to test this in the release version of Pro Tools when I can save a session (once I get my PACE signing tools). I'll report back.

Thank you, @Christoph-Hart and @ps, for all of your help!