GUI glitch with AU in Logic Pro (JUCE 4.1)


#1

Hi, so i encountered the following Problem:

Logic creates certain context help tooltips (displaying positioning information etc.), i.e. when moving an audio region in the arrangement window.

The problem is, as long as my plugin editor window is open, the tooltips don’t disappear, even if i minimize the main Logic window (they’ll just hover over the desktop background).

As soon as i close the editor window, the tooltip disappears as well.

Does anybody have a hint how to fix that ?

Regards,
n


#2

Try adjusting your timer


#3

Thanks, i’ll try that … are there any recommendations for good timer values ? It’s currently pretty slow …


#4

set to taste.
Hope that worked for you


#5

Ok, so i tried tweaking the timer values, but this only uncovered a bigger problem.

As soon as i set the value < 200 ms, not only the Tooltips get stuck, but the Logic UI is blocked completely. I can’t move anything in the arrangement window as long as the plugin editor window is open, and the Logic VU Meters in the Mixer get horribly slow.

Now i’ve set it to 250ms, which makes it somewhat usable, but the overall reactivity is still impaired as long as the
plugin editor window is open …

Anyone got a hint what the reason might be ?


#6

when I had similar problems with badly reacting GUI and even slowing the meters of the host down, I could only solve that by removing any repaint call and ONLY call repaint inside the timer. I guess when one repaint came from the message thread and another by a callback, they lock each other badly. Just guessing…


#7

Did you adjust this
tooltipWindow.setMillisecondsBeforeTipAppears(?);


#8

No, didn’t touch that parameter …


#9

So, i now tried to disable all repaint() calls, to no avail.

Generally, it seems like GUI events are held back. Like, when i click on a region in the Arrangement window,
the first 3 or four clickcs go through, afterwards the Window stops reacting.

When i close the window, the clicks that were seemingly held back now pass and have their effect …


#10

Just to make sure, we are talking of the same thing:

This is how many gui updates work.
I think the tooltipWindow.setMillisecondsBeforeTipAppears(?); is unrelated, because it sets the juce tooltips, but your problem is that “dirty regions” from outside juce are not repainted, right?

If this timer callback works, you can start to optimize by calling repaint in the timerCallback only for certain child components or whatever is appropriate…

HTH


#11

Yes, pretty much, except that i call startTimer(ms); without the Hz, don’t know if that makes a difference ?

BUT it seems like the problem is to be found elsewhere, and (seemingly) unrelated …

As soon as i include a juce::ImageButton, the problem occurs. Now i’ve replaced all ImageButtons (there were three, using simple png graphics with a size of ~850 bytes) with standard TextButtons, et voilà, things work fine, even with a timer value of 100 ms.

Even when i exclude every complex GUI element and the LookAndFeel-Stuff, as soon as the ImageButton is added and made visible, the blocking phenomena described above occurs.


#12

No, it’s the same. Looking into the sources shows, that startTimerHz simply calls StartTimer converting the frequency into miliseconds.

The ImageButton thing is strange. I was looking into the Button and I found out, that has it’s own update mechanism like autoRepeat. So first thing I would try is to remove the ImageButtons from the timerCallback, i.e. not calling repaint on the editor itself but on all the sub children except the buttons separately.
Maybe that leads to somewhere.

If somebody else has a better view of what’s going on, please chime in here…


#13

Hmm actually i’m not even calling repaint(); on the whole editor window, just on a few Components like my custom VU Metres and a graphical Plot of Microphone characteristics …