if a graphics object is hidden on lock it will still cause some overhead, just as when hidden. for the pure visual hide/show thing, bringtofront/sendtoback of a white panel will do that just fine. other options would include unloading the bpatcher and load an emtpy one or using an offset in the bpatcher window.

Thanks Roman, if I understand you correctly, even when hidden, if a jitter object is still somehow visible within the embedding bpatcher it will consume resources, but if the bpatcher is offset so that the jitter object is out of the bpatcher window it won't ? Weird, huh ?

jitter is another story, jitter video can easily be stopped to process by not sending any further frames. so you would use a [gate] object to cut off the bpatcher´s input, and it will be silent.

but things like a numberbox or multislider are often still requried to process (because people use them this way) and then they still require some CPU more even when the changes are not drawn.

Here I'm dealing with typically scope objects drawn using jitter (like the stock M4L LFO of Live). Not typically video but updated regularly. Thus, stopping the background update if the element is not shown is what needs to be done here ?

i would already turn off the audio input to the jitter objects, or at least the frame clock (wherever that comes from.) if it is really required for the pwindow when not shown... i am not 100% sure. but everything before it can also be turned off when it is not shown, isn´t it?

I have several live.scope~ that I probably can send active messages to when they are displayed or hidden. And an oscilloscope in jitter using jit.catch~ for which I probably can gate the clear and grab messages. As you say, not sure it will change a thing but these takes quite some CPU when shown (7 live.scope~at the same time)

i use empty poly~s to cut off signals from their destination. eventually the clock in a catch~ or poke~ still runs with no signal at th input (?) and you want to to "active" in addition.