<div dir="ltr"><div dir="ltr">Em qua., 4 de dez. de 2019 às 22:36, Miller Puckette <<a href="mailto:msp@ucsd.edu">msp@ucsd.edu</a>> escreveu:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">it's bad to copy information around and better to always have access<br>
to one centralized variable that you can check when needed. </blockquote><div><br></div><div>Ok, I think I get it now. Say you got controllers sending info and you want them to go through just when the patch is visible, then when the data comes in you check wether the patch is visible or not so you can let it through. Kinda like that, right?</div><div><br></div><div>I do that for the patch window that is in the 'top level' - cyclone has [active] for that but it sends you the status when it changes. Liam asked me for an object that would also give you the status of a parent patch. Never used that, but I guess I can see why you'd need it for abstractions. </div><div><br></div><div>Likewise, maybe you want something to happen only if the parent patch containing the abstraction is visible - seems to be useful if your abstraction generates interactive graphs, for instance, and there you have it, a use case. I do have an abstraction that generates spectrographs for display in ELSE and then I could turn its DSP off (with [switch~]) when it's not visible and needed. So it seems I found a use case after all, I'll try this out.</div><div><br></div><div>cheers</div></div></div>