ComboBox / PopupMenu sending wrong value to AudioProcessorValueTreeState in AUv3

I’m having a frustratingly strange problem. I’ve verified it is the same with either PopupMenu or ComboBox (unsurprisingly).

If I create either, then attach them to my ValueTreeState, they work fine in all the desktop versions, and in iOS Standalone, but in the iOS AUv3, they’re sending the wrong values. In this example, there are four items in the list.

ctrl_combo_recmodes.reset(new ComboBox());
ctrl_combo_recmodes>addItemList(valueTreeState.getParameter(String(ParamID::kInputMonitor))->getAllValueStrings(), 1);
attachCombo(valueTreeState, ParamID::kInputMonitor, ctrl_combo_recmodes.get());

The attachCombo is just a little helper function to call AudioProcessorValueTreeState::ComboBoxAttachment.

As I said, in the desktop and standalone versions, everything is correct. In the iOS AUv3 version, if I select items 1 or 2, the ValueTreeState gets set to item 1 (float value 0) and if I select items 3 or 4, ValueTreeState gets set to item 2 (float value 0.25f).

I’ve tried this with a PopupMenu and setting the parameter value directly as well, with identical results. I can set the value correctly using the generic controls in the host (in BeatMaker 3 and GarageBand), and when I go back to the UI, the ComboBox reflects the correct value. But as soon as I make a selection from the UI, the error returns.

Any thoughts? I’ve used a metric cockton of PopupMenus and ComboBoxen in our other 11 (!) AUv3 products, but this is the first time we’re using ValueTreeState for our parameter management.

1 Like

Further to this, just following along in the debugger, the value sent from the popup is correct. When I select the fourth item, result is indeed 4. So the issue is further along the chain.


That’s odd. I’ve just had a go at reproducing it in a really simple AUv3 that just contains a ComboBox attached to an AudioProcessorValueTreeState and periodically prints out the ValueTree and the normalised values are correct. Can you put a breakpoint in ComboBoxAttachment::comboBoxChanged() and see if the newValue is correct there?

I was about to do what you asked, and I just discovered that if isDiscrete in createAndAddParameter is set to “false,” it works fine. We had it true because, well, it’s a list of modes, and that’s theoretically what it’s for.

In further experimenting, setting isDiscrete true to any parameter makes it so it won’t sync with the UI. This includes sliders and buttons.

The plot thickens. I can use isDiscrete false, so I’m okay now. Of course, one can’t grab the list of item names directly from the parameter in the combo box’s constructor without it being true, but we all learn to live with life’s little disappointments.

OK, thanks for the info. We’ll take a look at it.

Please give this a try on both your old and your new APVTS AUv3s:

Without isDiscrete the automation lanes won’t display a nice stepped curve.

If everything looks good then I’ll cherry pick this to the master branch.

This appears to fix it on initial tests. I’ll post in this thread if I find any other issues, but as far as I can tell on first look, that solved it. Thank you, good sir!

Yeah, and getAllValueStrings() is working again as a result; okay. All-around win. As far as I’m concerned, this seems fixed.

1 Like