Strange that I can’t recreate this here locally. If you switch to openGL, and then close the plugin window and reopen it, do the problems persist?
No time for any instruments this summer. Just furniture and I have a red cedar roof to install in a few weeks time 
When you refresh the plugin, hiding and showing it, the black lines are erased, both in Reaper, Logic, Cubase, etc. So it’s like it doesn’t update? 
What happens with 200%, is only in REAPER. Everyone else does it as expected.
A very grateful job making furniture. If you give them the finish that you gave to the mandolin, they will be beautiful.
Well … And above all, I have to see those photos of the ceiling lined in cedar wood, yes or yes 
It’s actually the outside roof I need to do. I’ll send a pic when it’s done. It’s a lovely wood to work with.
I wonder if we should force the plugin window to close when changing modes? We display a popup explaining that the plugin will need to close in order to make the change?
I’ll try a few other things first to see if we can avoid this, but this might end up being the cleanest way.
Sure it will look great
I don’t know if this occurrence will be feasible, but is it possible to recreate something like the latency () control in form? I have noticed that using openGL () from form, it does not render the black lines.
What happens is that when you save the session and reopen it, the black lines follow
Even when openGL is already enabled? If you set openGL(1) in the form, does this still happen, or does everything work then as expected. I’m beginning to think that swapping modes might be a little hit and miss. I can’t see any black lines in the last beta version. So I can’t even try to debug the problem.
In form With openGL (1), black lines do not appear. Those are the last tests I was referring to yesterday.
Anyway, it may even be the openGL version of my graphic card, which in my case is 3.1. Maybe with 3.3 it would not happen. I don’t know if that can make a difference 
Seems I’m using 3.3. On the other hand, I think so long as you have v3 or higher it should be Ok.
I’ve just now pushed a change to the size of the image cache in the openGL context. I read that increasing this limit can improve things. I have it set to 32Mbs now, but we can also try 64Mbs if this makes no difference. I’m also calling a repaint() as soon as we swap. Hopefully this will help. And if not, we try again 
Tests with 2.7.9:
I notice that everything goes faster, but it still does not redraw correctly.
With percentages like 100%, or 200% it doesn’t happen, but with divisions it does.
It’s as if the JUCE_OPENGL_ALLOW_NON_POWER_OF_TWO_TEXTURES flag is being ignored somehow? Adding that fixed all the problem I was having. And a quick search through the JUCE forums seems to indicate that this is the most common fix for these issues. For instance, check this thread. I wonder if it might be the openGL version?
Anyhow, I just bumped up the openGL cache size again. Let me know.
updating openGL cache size 2.7.9:
Follow the problem
In the Juce forum, they focus almost all the time on this flag, but there is no mention of which versions of openGL affect this. You are fine with 3.3, but I think 3.1 is not 100% suitable.
Here’s something interesting about contours:
repaint (), is it already adapted?
Yes. I’m afraid so. I’m pretty sure people in many of those JUCE threads are using newer versions of openGL, but still see the issue. Are the mouse coordinates still wrong when you set openGL(1) in your form declaration?
openGL (1) in form declaration:
It does not generate any type of contour (not black lines)
REAPER 200%, wrong coordinates (in Cubase, Live, Studio
One, etc., does not happen)
Resizing responds in a less agile way, but it is
correct.
The first tests were done in this way, but later the contours appeared with the disconnection option.
I have quite many widgets here, trying to run on a MacBook Pro (Retina, 15-inch, Mid 2015) with MacOS 10.14.6 in Ableton Live 9.
With plugin GUI window open I get 15% CPU, while this goes down to 2% when the window is closed. Of course plugin running in standby in both cases.
It seems that the openGL does something - I notice some red background blink when resizing and some deformed circles. Btw. only for the tiny ones, e.g.
image bounds(136, 94, 5, 5), shape("cicrle")
But it doesn’t seem to make a change on the CPU meter in Live. Do you have any clue or additional info?
You may or may not notice any difference in UI performance when you switch to openGL. In my tests I was only able to achieve gains in instruments that were constantly redrawing a lot of elements. Are you doing this? 15% when the UI is open does seem a little much. Can you PM me your code again and I will try it through the profiler in XCode. The usual culprits for this kind of spike is called cabbageSet too often.
When your plugin runs (it’s very nice btw!), the same level of CPU is seen when the editor is open, and when it is closed. When I muted disabled the metro, and let it get quite the CPU dropped right down to 0. So I put a breakpoint in the process block function and it wasn’t getting called at that point. So it seems that Live has some way of dynamically enabling/disabling plugins to free up CPU. At least that is my read. Otherwise there is no reason in the world it would stop calling the process block function.
I also ran the instrument through the profiler. No surprise that the opcode hit the most is cabageGetValue. You do query a lot of channels on each k-cycle? The following is one such example right?
kSaveOFFTrig[] fillarray \
trigger(cabbageGetValue:k("IO_SavePar1"),0.5,1),\ ;1->0
trigger(cabbageGetValue:k("IO_SavePar2"),0.5,1),\
trigger(cabbageGetValue:k("IO_SavePar3"),0.5,1),\
trigger(cabbageGetValue:k("IO_SavePar4"),0.5,1),\
trigger(cabbageGetValue:k("IO_SavePar5"),0.5,1),\
trigger(cabbageGetValue:k("IO_SavePar6"),0.5,1),\
trigger(cabbageGetValue:k("IO_SavePar7"),0.5,1),\
trigger(cabbageGetValue:k("IO_SavePar8"),0.5,1),\
trigger(cabbageGetValue:k("IO_SavePar9"),0.5,1),\
trigger(cabbageGetValue:k("IO_SavePar10"),0.5,1),\
trigger(cabbageGetValue:k("IO_SavePar11"),0.5,1),\
trigger(cabbageGetValue:k("IO_SavePar12"),0.5,1),\
trigger(cabbageGetValue:k("IO_SavePar13"),0.5,1),\
trigger(cabbageGetValue:k("IO_SavePar14"),0.5,1),\
trigger(cabbageGetValue:k("IO_SavePar15"),0.5,1),\
trigger(cabbageGetValue:k("IO_SavePar16"),0.5,1)
I wonder would you get better performance now with the new cabbageChanged opcode. It this case alone it would lead to 30+ less calls to different opcodes. Worth a shot. But in general I don’t think the CPU is bad considering what it does.
Thanks for checking this. Yeah, I have 100+ widgets to cabbageGetValue from.
I suspect reducing the number of automatable channels could help with the overhead in Ableton? Because in Cabbage IDE, the CPU behaves as expected.
So you didn’t notice a dramatic (in my case 15%) change when toggling the plugin GUI ON/OFF? Right button:
I’ll try modifying the trigger code above with cabbageChanged. Thanks for the suggestion. But I have two puzzles here:
Yeah, I’d so soemthing like:
kVal, kTrig cabbageGetValue "button1"
if kVal == 1 && kTrig == 1 then
I think that should be fast enough.
No, I see this too. But as I wrote yesterday, the drop only occurs when I have no audio coming from the plugin. If the plugins is producing sound I get no drop in CPU. But as you said, this is only when the plugin is in standby mode, i.e, idle. It looks like Live somehow disables the plugin when it’s idle, hence the massive drop in CPU.
We’re kind of veering off topic here, but here is an example that quickly checked which radioGroup button has changed. But I see the dilemma when you only wish to be notified when you hit a target value. Let me see if I can add an optional changedTo argument. The idea being that it will only trigger when the channel hits the changedTo target value.
<Cabbage>
form caption("Radio") size(400, 300), guiMode("queue") pluginId("def1")
checkbox bounds(10, 10, 100, 30), text("Check 1"), channel("ck1"), radioGroup(10)
checkbox bounds(100, 10, 100, 30), text("Check 2"), channel("ck2"), radioGroup(10)
checkbox bounds(200, 10, 100, 30), text("Check 3"), channel("ck3"), radioGroup(10)
checkbox bounds(300, 10, 100, 30), text("Check 4"), channel("ck4"), radioGroup(10)
checkbox bounds(10, 100, 100, 30), text("Check 1"), channel("ck2_1"), radioGroup(20)
checkbox bounds(100, 100, 100, 30), text("Check 2"), channel("ck2_2"), radioGroup(20)
checkbox bounds(200, 100, 100, 30), text("Check 3"), channel("ck2_3"), radioGroup(20)
checkbox bounds(300, 100, 100, 30), text("Check 4"), channel("ck2_4"), radioGroup(20)
</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -M0 -m0d
</CsOptions>
<CsInstruments>
; Initialize the global variables.
ksmps = 32
nchnls = 2
0dbfs = 1
instr 1
SRadioGroup1[] cabbageGetWidgetChannels "radioGroup(10)"
SRadioGroup2[] cabbageGetWidgetChannels "radioGroup(20)"
SChangedRadio1, kTrig1 cabbageChanged SRadioGroup1
printf SChangedRadio1, kTrig1
SChangedRadio2, kTrig2 cabbageChanged SRadioGroup2
printf SChangedRadio2, kTrig2
endin
</CsInstruments>
<CsScore>
i1 0 [60*60*24*7]
</CsScore>
</CsoundSynthesizer>Thank you for additional explanations!
And thanks for the new trigger - looking forward to implement it.