Where to put initial startup parameter values for AAX?

General JUCE discussion
21

Could all this be caused by some race condition considering that get/setState may happen on non-message threads?

There is a flag to tell Pro Tools to operate on the message thread, see here: [AAX][PULL REQUEST] Force Protools to do chunk calls in message thread option

22

Thanks for the heads up - I’ve inserted that code, but it doesn’t help this situation, unfortunately.

23

OK, I’ve found a way of hacking setState to use my initial setting, if it’s the first time the plug-in is loaded. It’s pretty ugly, but at least it’s out of the Editor now.

24

Why? If you make a distinction between “initial” and “default” then the user has no way to get back to the “initial” state other than de-instanciating and re-instanciating the plug-in.

I’m curious what your use case is.

25

I’d like to use ‘default’ as a neutral, or null position, so basically 0 for a knob as an example. When the plug-in first loads up it would be nice to set an example of what the plug is capable of. I would normally have presets but the plug-in is so basic that I don’t have any. You could always set default and starting value to be the same.
But never mind, I’ll work around it… :grinning:

edit: It also appears that get & ‘setCurrentProgram’ are not called at all when the number of programs is 1, which would help a little I think.

26

Setting that to 1 basically means there is only the “default” program, not that there is a set of programs which happens to only have 1 member. So there should be no need to load a program in that case. (And I believe that this is controlled by the host, so JUCE couldn’t enforce such a change, anyway.)

27

So I can’t set a preset on single program plug-ins, and I can’t set values in the constructor of the AAX processor. Never mind, I’ve worked around it now.

28

Hi @DaveH,

I’m curious about your workaround as I found out I have the same problem in all my plugins. I allow the user to define the intial state in a preset and load that inside the constructor. Unfortunately Pro Tools does not pick up these values, but instead uses the default values I used when setting up the parameter. So the exact same problem. In addition to ignoring my parameter changes during the constructor, it seems PT also sets parameters to their default values after construction - in the process the changes I make are lost.

I’m considering multiple workarounds, but what I came up so far definitely is ugly. What did you end up with?

29

Hi @pflugshaupt, just after I add the listeners, I just run through all the parameters and call parameterChanged:

	for (auto* param : getParameters())
	{
		if (auto* p = dynamic_cast<AudioProcessorParameterWithID*> (param))
		{
			AudioProcessorParameterWithID* par = pluginParams.getParameter(p->paramID);
			float v = par->getValue();
			par->sendValueChangedMessageToListeners(v);
			NormalisableRange<float> nor = pluginParams.getParameterRange(p->paramID);
			v = nor.convertFrom0to1(v);
			parameterChanged(p->paramID, v);
		}
	}

At least I think that’s the code. There should be a better way, of course.

1 Like
30

I think the best way nowadays is just to define the JucePlugin_AAXDisableDefaultSettingsChunks preprocessor definition to instruct Pro Tools that it should just not do that. Has been added quite a while ago to JUCE AAX: Added JucePlugin_AAXDisableDefaultSettingsChunks flag to set th… · juce-framework/JUCE@17d9675 · GitHub

3 Likes
31

Thank you both for the quick responses! I found in the meantime that in my case, the problem was the aax default values that are set when parameters are defined. Pro Tools would then just send these back to my plugin after each ctor. This totally messed up my own user-definable init state/chunk applied as the last step in the ctor.

Anyway, JucePlugin_AAXDisableDefaultSettingsChunks looks exactly like what I need - as I have my own default chunks. Weirdly enough, I have never seen that setting until now and I see it’s not exposed in ProJucer - maybe that’s why. I guess it’s time for me to read through all those JucePlugin_ macros.

1 Like
32

Wow, thanks. That’ll tidy things up a bit!

33

We use that flag, and it worked fine in Juce 6 perfectly. But now in Juce 7 our override of CompareActiveChunk() is not called when that flag is defined, which breaks our plugin’s ability to control the Compare button state in Pro Tools. It seems that if that flag prevents calling GetChunk(), then there is no longer a “Default” chunk at all, and so the Compare button and the Default presets do not do anything. We’re stuck how to get Compare to work and fix the problem described in this thread at the same time.