Visibility issue Ableton Live


#1

Hey dear members,

I actually don’t know if the following also occurs in other DAWs but I can’t test other DAWs right now. Following steps create the problem:

  • open the plugin editor of my synthesizer.
  • without closing select another track.

The plugin editor won’t get closed and JUCE reports the windows as being visible. So in the background it still gets redrawn even though I can’t see it. I see why it won’t get closed but why is it still visible?
Our synthesizer uses animations when playing a note. If you arm multiple tracks they all get redrawn in the background without the need for it. Is it possible to detect whether the plugin window gets hidden in this way? Like I said, Juce reports it to be visible.

Best,
Thomas


#2

with isShowing() ?


#3

isShowing() also returns true.


#4

Can anybody confirm this?


#5

This is still a problem!
Again, it happens like this:

  • Open a plugin editor.
  • Select another track.

The plugin is now not visible anymore but it will still get repainted in the background (a timer triggers frequent repaints in our oscilloscope. Animations are used, when notes are played). This is a problem if multiple instances of our plugin are opened like this. I printed the following debug messages (TLC being the top level component):

Editor: Is visible: yes
Editor: Is showing: yes
Editor: Is on desktop: no
TLC: Is visible: yes
TLC: Is showing: yes
TLC: Is on desktop: yes
Peer: Is minimised: no

I also set a breakpoint in the NSViewComponentPeers toBehind() method, but that is never entered. I would expect the editor not to paint anything when the window is not actually visible.


#6

Just a guess, but perhaps the window is simply behind other windows? That would still be considered visible. It’s up to the DAW how they handle their plugins’ windows, and whether they close the windows, minimize them, or simply push them behind the main window. Some DAWs have a setting that keeps plugin windows “on top”, so that the main window never obscures them like that. I don’t personally know of any way to test if any portion of a window is showing or not, which is what you’d need to know if you wanted to test if any drawing will ever be needed. (Assuming that’s what you’re looking to determine, in order to reduce redrawing?)


#7

Yes, I want to stop any redraws, when the window is not visible. Here is a small gif, that shows the behaviour. I select an empty midi track and the window is gone. The redraw is still happening.


#8

Unfortunately, I don’t know any way to prevent that. I saw a couple of threads about redrawing to hidden windows, which seemed to indicate an Apple change back in El Capitan that led to this, but haven’t seen a solution or indication that Apple fixed it. Windows that have no visible areas should just not ever get redraw messages, I would expect. But if they do, then what are we, as plug-in developers, expected to do about it? It just doesn’t seem reasonable to have us making platform-specific calls to test if any portion of our plug-in’s parent window is visible or not. Anyone know if there is a reasonable fix for this behavior?


#9

I can confirm this is happening for our plug-in too with JUCE 5.4.1


#10

Could anybody from the Juce team join in on this?


#11

I have a 2nd window that is required to be “always on top” otherwise it is always behind the main plugin window in Live. But then when Live hides the main plugin window my secondary window is remaining on screen (always on top of every other window!). This is a quite a pain. Knowing when the main plugin window has been hidden by Live would be incredibly useful in this situation too.


#12

I know, this is annoying, but I would at least like to get an opinion from the JUCE devs on this. I’d like to dig into fixing this. But I don’t know where to look. Is it realistic that this even can be fixed?


#13

As Howard suggested - you’re at the mercy of the DAW here. Probing the window order is likely to be very difficult, but perhaps not impossible. If you find something that works (and isn’t completely horrible) then we’ll gladly incorporate it…

If you can avoid opening additional windows from your plug-in then I would strongly suggest you go the single-window route, especially if you’re doing something like running a modal loop. This is almost guaranteed to cause problems similar to this.


#14

I think there is a misunderstanding here. I only have one plugineditor. The problem is when the user instantiates more then one editor in different tracks. Live somehow hides the other instances, when I select another track. I’d like to stop those hidden plugineditors from repainting, even though they are not visible anywhere. I don’t think that’s a problem of window order as seen in the gif.


#15

There’s no misunderstanding, just a poorly worded post from myself. Substitute “window order” with “window management”.


#16

That was in reference to the additional windows which I don’t have. But ok. Maybe I have to live with it.


#17

… and that was a response to richie who spoke about having an additional window in the post immediately before yours.