JUCE 5.4.1 Slow GUI

Audio Plugins
1

Hello,

After updating to JUCE 5.4.1, one of my plugin has very slow gui response issue.
This plugin has about 1300 parameters and if I don’t add parameters with “createAndAddParameter”, gui works normally.
And also if I compile with JUCE 5.3.2, gui works fine.

So I guess this is related to new AudioProcessorValueTreeState stuff.
Does anyone else have similar issue?

Thank you

2

What’s displayed on your GUI?

3

The plugin GUI has lots of sliders and buttons.

I tested with 100 parameters and it’s fine.
With 500 parameters GUI response starts to become slower.

The plugin works just fine with 5.3.2.

4

So you have 1000 on-screen sliders? I’m just trying to see what it would take to reproduce the issue in a simpler plug-in.

5

The plugin has tabbed windows.
So about 160 sliders and 100 buttons on the GUI at once.

6

Hi !
I may have a similar problem.
I am using in a very simple plugin (5 sliders) the following code for one of the slider:

parameters.createAndAddParameter ( "l1Volume",       // parameterID
                                          "Volume",       // parameter name
                                          "",           // parameter label
                                          NormalisableRange<float> (-1010.0f, 12.0f,    // range
                                                 [](float start, float end, float gain) { return (float)cv01todB((float)gain); },
                                                 [](float start, float end, float dB) { return (float)cvdBto01((float)dB); }),
                                          -6.0f,         // default value in dB
                                          [] (float p) { return dBToStr(float(p)); },
                                          [] (String str) { return (float)dBstrToDbl(str) ; });

The functions cv01todB and cvdBto01 are very simple functions that convert the [-1010 +12] range to [0 1] and reciprocally.
I added a trace to these functions, and a counter to know how many times they were called. I also generated the application with JUCE v5.3.2 and JUCE v5.4.1.
Here are the results (number of calls):

  • launching the standalone plugin:
    JUCE v5.3.2: cvdBto01: 2 times, cv01todB: 2 times
    JUCE v5.4.1: cvdBto01: 279 times, cv01todB: 7 times
  • clicking on the widow title bar, then clicking in an other application:
    JUCE v5.3.2: cvdBto01: 0 times, cv01todB: 0 times
    JUCE v5.4.1: cvdBto01: 6 times, cv01todB: 0 times
  • clicking somewhere in the slider:
    JUCE v5.3.2: cvdBto01: 4 times, cv01todB: 1 times
    JUCE v5.4.1: cvdBto01: 25 times, cv01todB: 5 times
  • clicking in another slider or hoovering the mouse over the slider:
    JUCE v5.3.2: cvdBto01: 0 times, cv01todB: 0 times
    JUCE v5.4.1: cvdBto01: 6 times, cv01todB: 0 times

Each time, the pattern is the same in 5.4.1: there is 1 or more sequences of 3 calls to cvdBto01:

[200000441]  dB->01   -0.545465 --> 0.556425  ~~   -0.545465
[200000442]  dB->01   0 --> 0.672414  ~~   0
[200000443]  dB->01   0 --> 0.672414  ~~   0

One call for the actual position of the slider (here, at -0.545 dB, corresponding to the physical position 0.556425 in [0 1]), then 2 calls to convert value 0 dB (corresponding here to the physical position 0.672414). Note that 0 dB is not the default value for the slider, the default being -6 dB. (the trace displays the # of calls so far, 441 to 443 in this case).

So I imagine, if I had a hundred of such sliders, each one with a function being called a dozen times, that the interface may become quite slow…

Hope this simple example may help finding the bug in 5.4.1.

Regards.

2 Likes
7

One big difference i noticed is, that the latest JUCE now notifies parameter changes also if the parameter value stays the same. I like that new behavior. Maybe it worked in the older JUCE version accidentally because it didn’t notify param changes with the same value.

8

OK, one part of these issues has been fixed:

The recent changes had accidentally introduced an O(N^2) lookup of parameter values, which was previously O(N), but has now been reduced to O(1). This will mean it’s slightly slower for a small number of parameters (but in this regime it’s consuming negligible CPU anyway), but much much faster for a large number of parameters.

9

Isn’t std::map lookup O(log N)?

Was there a reason for not using std::unordered map here? Maybe because it uses a juce:: String as the key?

10

Ah yes, O(log N).

JUCE’s live build engine can’t compile std::unordered_map. I’m not sure why but Stefan had a good go at it a while back and ended up admitting defeat.

11

Hi !
I have recompiled my project with the today develop branch of JUCE, with no change: still get hundreds of calls to the conversions functions.

I have put my project on github, so you can have a look a it.
It does a lot of traces using DBG, so you can check what’s happening.

Regards.

https://github.com/jack461/Orangejuce.git

12

Are you sure you are having performance problems because of the conversion function calls? Modern CPUs should be able to do tens of millions of those per second easily.

13

I’m not talking about performance problems: when I just launch the application, compiled in JUCE 5.4.1, doing nothing else, I get 275 calls to the conversion function for just 1 slider, while I have only 3 calls with the version compiled in 5.3.2…

1 Like
14

Thank you for your update.
I just compiled my plugin with latest develop.
And now my GUI works fine like as JUCE 5.3.2.

1 Like