Site navigation

Safe to skip nullptr check for APVTS parameter pointers?

Audio Plugins
#1

In my plug-in code, I’m using a couple of the AudioProcessorValueTreeState methods that return raw pointers - getParameter and getRawParameterValue.

Would it be considered safe to just check one time that these pointers are not nullptr (e.g. asserting in a constructor that the parameter specified in their parameterID does in fact exist), but then not continually check for nullptr after that point, every time you want to use one of the pointers?

As far as I can tell, you cannot remove parameters from an AudioProcessorValueTreeState, and while technically you could destroy the AudioProcessorValueTreeState itself in your plug-in code, that would cause all kinds of hell to break loose. So, it would seem that you have a guarantee that those pointers will be valid for the lifetime of a (sane) plug-in instance. Is that a safe assumption to make?

#2

I would say that is correct. The system is not designed to destroy the APVTS. While you could theoretically do that, there would probably many things break.

I do the lookup in the constructor and assign it there to a dynamic_casted variable. The next line is always a jassert with that pointer, so I will always know in a debug build, if I broke something (e.g. renaming a parameter ID or accidentally removing a parameter). After that there is no need to check over and over.

#3

Thanks for lending your expertise to the question. It made sense to me that APVTS parameters and their pointers would be stable, but I wanted to make sure I wasn’t overlooking some important edge case.

I’m curious, what is the dynamic casting that you’re doing? Do you mean casting the RangedAudioParameter pointer as a [AudioParameterBool, AudioParameterChoice, AudioParameterFloat, AudioParameterInt] pointer?

#4

Yes exactly. This way parameter.get() returns thread safe the correct type, or getCurrentChoiceName()/gettIndex() in case of AudioParameterChoice.