AudioProcessorParameter meters


#1

How is this suppose to work?

I guess: The plugin pushes new metering values whenever a certain amount of samples are processed? The DAW then has the option to display those meters, and takes care about all display internal calculation (i.e. fallback, peak hold, etc.)

The AudioProcessorParameter meters seem to be presented in Cubase as read only parameters, but it seems there is no graphical metering displaying those values despite displaying it as a static parameter controller value in the generic plugin view.

If thats correct I think using the AudioProcessorParameter as means of transmitting metering data makes no sense.

I know that Protools displays - at least reduction - meters correctly. Is it also capable of displaying other meters correctly? How can I see those?

Which DAWs really support plugin meters? And especially which DAW is using the AudioProcessorParameter metering provided approach?


#2

…and to add another question, does it work together with AudioProcessorValueTreeState?

I don’t see, how you would create one, as createAndAddParameter has no option to do so, and I also see no way to add a previously created AudioProcessorParameter.


#3

… and would AudioProcessorParameter based meters not require the ability to dynamically remove those parameter (i.e. as a reaction to channel configuration change)?


#4

I don’t think that the above are terribly difficult questions that can’t be answered for weeks. What the silence probably shows is, that the parameter approach to transmit metering data is not well thought thru despite that there is probably no use for it (yet).

One of the most important requirements is that such parameters can be removed (to follow channel layout re-configuration).

I really would like to make a decision now of how our plugins are going to organize meter handling.


#5

The only format which properly supports meters is AAX. AAX will only record one meter value per processBlock callback so it’s advisable to set the meter value on each processBlock callback and that meter value should represent the buffer that was just processed.

Currently, JUCE only supports a static set of meters - so there is no way to dynamically remove/add meters.


#6

Thanks fabian,

so, how is this intended if meters can’t be removed: The plugin creates as much channels as it supports, but only updates the meters for the number of channels it actually uses?

Does the plugin actively (i.e. SetValueNotifyingHost()) pushes the new value to the host, or does the host eventually requests new meters?


#7

Well we are working with the limitations of AAX: ProTools will only show a single meter for all of the channels. There is no way to show multi-channel meters. In fact, ProTools only supports a maximum of one gain-reduction meter - for example.

For AAX it’s technically not needed to actively push the meter values but if you want to also support generic editor meters in VST/VST3/AU then you will need to actively push the values. It can’t harm in any case.


#8

Thanks for the clarification, fabian!

But for generic editor meters (are the generic UIs really intended for metering?), the plugin would need to provide the fallbacks, or the meters are jumping or statically stay at the last value…

But if the plugin provides the fallbacks they would differ from the user settings in the DAW (so I doubt thats the right approach…) also there would be no way to indicate and hold a max value.


#9

Yes you are right. But I don’t think anybody uses the generic editor views anyway. It might be a good way to quickly debug some audio though.

That’s also true but this is not a limitation of JUCE but of the plug-in formats.


#10

Agreed.

Yes, (thats not what I am saying).
I am trying to make a decision of whats the right approach to organize meterings. I really like the idea of (ab)using the parameters but I doubt its a good idea though.


#11

Well, in this case PT probably calls AudioProcessorParameter::getValue() which is market const but needs to be able to reset its internal value.


#12

Well you can do this yourself at the beginning of your processBlock callback: AAX will always want exactly one meter value for every processBlock call.


#13

Thanks fabian,

I would consider this a hack circumventing OOP: is this also true for other hosts?


#14

No, other hosts will simply display the last value that you sent with notifyHost.