Radio button issue

PluginGuiMagic
1

Hi, having issues with radio buttons. the projects open with them all checked, but they are not active. They can be unchecked but that is all?

2

Sorry for the late reply.
Did you solve your problem?
I haven’t been able to reproduce this.
First question, did you use the develop or the main branch?
Cheers

N.B. I just pushed a new version to the main branch 1.3.8
The SignalGenerator example uses the new RadioButton manager and I just checked it worked here…

3

In the develop branch, I am seeing a second gesture being started by RadioButtonHandler::buttonClicked before the main ToggleButton’s onClick (mouse-up) handler has finished its gesture. Could they be on separate threads now? I don’t know when this appeared, but possibly when I upgraded to Mac OS Ventura 13.1. I’ll drill down further as soon as I need a RadioButton if not before. In the meantime, I’ve disabled RadioButtonHandler with this workaround:

diff --git a/State/foleys_RadioButtonManager.cpp b/State/foleys_RadioButtonManager.cpp
index 1ac2a43..3a17d2c 100644
--- a/State/foleys_RadioButtonManager.cpp
+++ b/State/foleys_RadioButtonManager.cpp
@@ -44,12 +44,19 @@ RadioButtonHandler::RadioButtonHandler (juce::Button& buttonToControl, RadioButt
     radioButtonManager(manager)
 {
     radioButtonManager.addButton (&button);
+//#define GESTURE_WITHIN_GESTURE_BUG_FIXED
+#ifdef GESTURE_WITHIN_GESTURE_BUG_FIXED // JOS temp workaround
     button.addListener (this);
+#else
+    DBG("*** RadioButtonHandler is DISABLED until the double-gesture bug can be found and fixed");
+#endif
 }
 
 RadioButtonHandler::~RadioButtonHandler()
 {
+#ifdef GESTURE_WITHIN_GESTURE_BUG_FIXED // JOS temp workaround
     button.removeListener (this);
+#endif
     radioButtonManager.removeButton (&button);
 }
 
~
4

Thanks for the report. I can replicate the problem and am looking for a fix.

I don’t think it can come from different threads, AFAIK the message queue is always single threaded on mac.
And the crash happens here on Monterey too (12.6.2), so it’s probably unrelated to the update either.

I added some safety measures on develop, including SafePointers instead of raw pointers, and fixed a wrong destruction order in MagicBuilder. Unfortunately that is still not the full solution.

EDIT: I just found a dangling parameter listener, which caused the crash. I added a fix to develop, please let me know if it solves the issue. If it does I will push the new version to the main branch right after new year.

5

I am unfortunately still getting this assertion triggering:

   #if JUCE_DEBUG && ! JUCE_DISABLE_AUDIOPROCESSOR_BEGIN_END_GESTURE_CHECKING
    // This means you've called beginChangeGesture twice in succession without
    // a matching call to endChangeGesture. That might be fine in most hosts,
    // but it would be better to avoid doing it.
    jassert (! isPerformingGesture);
    isPerformingGesture = true;
   #endif

I added JUCE_ASSERT_MESSAGE_THREAD to Button::setToggleState, and it does not fire, so that’s ok as you thought. I’ll test some more tomorrow after a deep clean and reboot. My experience with AU* plugin development to date indicates not to trust that a simple rebuild in Xcode will replace the previous state of everything. Things magically work then fail then work, all based on the same code.

6

Ok, I am still seeing this after rebooting et al. The problem seems to be that a Button click-listener is starting a gesture during the gesture of the main click, where the listener is the RadioButtonManager.

7

It turns out Button::setToggleState is called from other than the Message Thread by some hosts, according to pluginval (which I am using for validation testing - the assertion I put there finally fired).

8

I still wonder what I am doing differently. I use the button-radio-group and button-radio-value in the SignalGenerator example.
Then I tested in Logic and as stand-alone. It behaves as it should for me.

9

Hi,

Sorry to revive an old thread. I wanted to report that I’m still having this exact issue. I’m on Windows, using the latest version of JUCE and PluginGuiMagic. I’m using JUCE’s AudioPluginHost for testing.

In Debug, I get the same assertion as @jos

#if JUCE_DEBUG && ! JUCE_DISABLE_AUDIOPROCESSOR_BEGIN_END_GESTURE_CHECKING
    // This means you've called beginChangeGesture twice in succession without
    // a matching call to endChangeGesture. That might be fine in most hosts,
    // but it would be better to avoid doing it.
    jassert (! isPerformingGesture);
    isPerformingGesture = true;
   #endif

In Release, the plugin doesn’t crash but the radio button stops responding alltogether. Has a workaround been found yet?

10

Thank you for the report.
As it stands, I will add a compile define to disable the RadioButtonManager until I found a fix.
Unfortunately that will disable any kind of RadioGroup, because the standard juce radio group feature cannot work, because it only works for siblings. Thanks to the wrapping/decorating GuiItem, no custom component is ever a sibling.

11

I’m facing a similar problem, which seems to be the same bug.
There’s a few things to it:

  • first it seems the buttons are the wrong way round, so if the parameter is off (or value 0) the button is ticked and if the parameter is on (or value 1) it is unticked.
  • the button only works in one direction. I can switch it to off but not back on. If I switch the parameter back to on (via the parameter itself) the button will react to that change and I can turn it off again.

Also it will run into an jassert in beginChangeGesture() and endChangeGesture(), so it seems they are called in a wrong order.