Hi there!
Working on some linked parameter logic for a JUCE-based AAX plugin, and it seems it is not currently possible to implement linked parameters the way that Avid specifies in their documentation. Their linked parameter docs indicate that parameter notifications should be sent when a parameter is “touched”, either from the plugin’s GUI or from an external client such as a control surface. The latter requires that the plugin be notified when UpdateParameterTouch is called outside of the plugin, but the juce_AAX_Wrapper does not currently inform the plugin of these touch changes, so my plugin cannot respond properly to touch messages/parameter updates from control surfaces (to the plugin, it incorrectly appears that control surface messages are just automation, so we can’t do the special logic for control surfaces).
This line from the AAX docs confirms that touch tokens can originate outside of the plugin, but JUCE is currently ignoring these:
Other clients besides the plug-in may touch a parameter. Since the TOUCH token can come from a control surface the touch state will actually come back to the plug-in via:...
The key point from the AAX docs that we can’t implement for linked parameters with the current JUCE AAX wrapper without external touch notifications is this:
the key rule for linked parameters is to link during real-time user edits only (where user edits are either from-gui or from-control-surface; any param change surrounded in touch)
Would it be possible to plumb these external touch tokens through to the JUCE audio processor parameters? Maybe calling beginUserGesture and endUserGesture on the param when UpdateParameterTouch is called in the AAX wrapper, so it can implement linked parameter properly? Or maybe some internal state in the AudioProcessorParameter like “isTouched” that the AAX wrapper can set without invoking the current side effects of begin/endUserGesture?
Let me know if more info is required.
I’ve just spotted this old thread… is this still the case or has there been work on this?
I don’t believe support has been added in JUCE, so I ended up doing some local JUCE mods to hook it up:
- in the JUCE AAX wrapper, implement UpdateParameterTouch:
virtual AAX_Result UpdateParameterTouch ( AAX_CParamID iParameterID, AAX_CBoolean iTouchState ) override
{
if (auto* param = getParameterFromID (iParameterID))
{
iTouchState ? param->beginControlSurfaceGesture() : param->endControlSurfaceGesture();
}
return AAX_CEffectParameters::UpdateParameterTouch (iParameterID, iTouchState);
}
Those beginControlSurfaceGesture and endControlSurfaceGesture calls were hookups I added in AudioProcessorParameter, and they drive some bookkeeping so that the plug can react to control surface gestures distinctly from automation.
Wow, that sounds great!
If there are any of the JUCE team reading… does this seem like a good addition to JUCE?
Thanks so much for sharing, @jackwcampbell .
I have an internal MR in which I was looking at this a while ago, I had put it down due to other things on my plate but I’ll try and pick this up again soon.
That would be amazing! Thank you, Anthony.
1 Like
Are there any equivalents in other plugin formats?
That’s something I wanted to look into but I’m not immediately aware of any.
1 Like
I’m sure you have lots of highly-demanded features in the works, @anthony-nicholls, and I suspect this one might not be top of the list… I don’t know if you’re able to share the MR you mentioned and I could see if I might be able to test it out in the meantime…?
@AdamVenn I had a look through and for the life of me I can’t find the MR, but I did find some of the work in some git stashes I saved. The work was a little more involved than I remembered and defiantly still in progress.
I think it’s worth saying the the solution given by @jackwcampbell should be sufficient for handling it all yourself and that would require minimal changes to JUCE for now. However, what I was looking to see if I could achieve at the time was a way to a manage all the logic required to handle touch events automatically without end users needing to do anything. I think it should be possible but it seems there were some knock on effects for other plugin formats. Most notable was you need to be able to handle touch events coming in for multiple parameters at the same time and some of the formats seem to currently expect only one parameter can be touched at a time (in most cases that’s probably true as it will currently only happen when a mouse is changing a parameter).
I would probably suggest following the path of least resistance for now and I’ll pick this up again once we have JUCE 8 out the door and things settle down again. Sorry I can’t help more than that just yet.
Thank you for the update and the advice, Anthony! Good luck with the ‘big 8’!
Has anyone else tried this? I don’t seem to be getting ‘release’ callbacks when I let go of the S1 knob having not made a gesture…
I got this working! Thank you @jackwcampbell, it works just as you wrote.
I ended up making an extra callback in the ParameterListener class distinct from parameterGestureChanged, which is called when ‘touch tokens’ are received. If something like that could be practical, @anthony-nicholls (and team), it would be really useful. AAX linked parameters do not seem possible without distinguishing GUI events and control surface events from recorded automation events.
