[AAX][PULL REQUEST] Force Protools to do chunk calls in message thread option

Forces Protools to do chunk calls in message thread if JucePlugin_AAXRequiresChunkCallsOnMainThread=1 is defined.

It prevents unexpected behaviors and potential crashes.

Please let me know your thoughts,


Could indeed be useful.

Guys ?


AAX says this behaviour is deprecated and you have to deal with this but this is handy sometime :slight_smile:

Well this code does work and does what it does.
Not sure this is what you needed in your default value issue though.

bumpity bump


post ADC bump :slight_smile:

1 Like

Please someone witness our effort to reach out.
Oh spirit of juce forum! if you are here with us knok 3 times!

1 Like

new year bump


Could be useful for legacy plugin when migrated to Juce and/or wrapped plugin

Thanks !

1 Like

Please let us know the reason if you do not intent to merge this pull request. Thanks

Let me join the bumpety bumpy bump train.


I’m not convinced it’s a good idea to add this feature. The docs for this feature flag say that it is supported “for now”, which implies that this might change in the future. Also, other plugin formats do not make guarantees about which threads may call the get/set state functions. A plugin that requires this feature will likely be broken when exported as an AU/VST3/etc, even if the issue is masked in the AAX version of the plugin. Ensuring your state functions are threadsafe will ensure that your plugin will work, even if the AAX_eProperty_RequiresChunkCallsOnMainThread feature is removed, or the plugin is exported in other formats.

1 Like

Besides AUv3, I don’t know any other format calling get/set chunk in non message thread.

Now I wonder what the best practice is for dealing with this.
If I use the AudioProcessorValueTreeState, as recommended, can I interact with this underlying state, a ValueTree, from get/set State or do I need to lock the state?
If so… there is no such thing as a ValueTreeLock, so perhaps locking the message thread is the solution?

I would not lock the message thread as a plugin, because as a plugin you are not fully aware what the host or other plugins do with the message thread, which will might easily cause a deadlock.

If so… there is no such thing as a ValueTreeLock, so perhaps locking the message thread is the solution?

I guess this is a weakness of the current APVTS implementation, there is a valueTreeChanging-CriticalSection, but its private, while the current valueTree is public and “You can replace this with your own ValueTree object” says the documentation, so if you deal with it from the messageThread you might get problems if another thread replaces the tree.

In this thread i discussed a similar problem.

For what it worth while you can call on message thread and block in get chunk like waitForExecutionOnMainThread done in AUv3.
In Set chunk waiting for the message thread to process the block will spin, so you need to use MessageManager::callAsync but don’t wait for completion.