On 07/15/2013 08:16 PM, Jonathan Wilkes wrote:
On 07/15/2013 05:40 PM, Miller Puckette wrote:
I tried this with four versions of a subpatch, one with "nothing" (just an inlet connected through to an outlet), one with a "float", one with hslider, and one with a number box (not "number2", just control-3 number). Subtracting out the control case, I sent 1000000 random numbers through and asked the cputime object how much time elapsed, and got approximately:
float hsl numberclosed 10 50 150 open 10 50 150
This was usin "until" to loop 1000000times. Trying the same thing with "metro 0.001" gives:
closed <10 50 150 open <10 60 200
That wasn't at all what I was expecting to see!
This was on a core 2 duo 7600 running at 1.6 GHz (my patch wasn't CPU hungry enough to make my CPU want to speed up), linux 3.6.3-1.fc17.x86_64 (Fedora)
cheers Miller
Getting back to the OP, I just want to point out that there are two separate issues at play here. I'll phrase them as a q&a:
Q: When inserting an iemgui for the patch author's convenience (or anyone else inspecting the abstraction), does it make a difference whether you put an iemgui in the main flow of the patch vs. outside of that flow (as Frank suggests)?
A: The answer is usually yes, _regardless_ of the cpu usage of the GUI object. It's always better to have one less object in the main object chain. If you just need to send values down the chain, add an iemgui as an additional input to the current object chain. If you want to see results of your patch in realtime, use the cord inspector which is available in both Pd-extended and Pd-l2ork.
There may be situations where you want to see a bunch of iemguis getting updated at once, but that's more likely to be a UI than something inside an abstraction.
Q: Are there times when it is useful to insert an iemgui into an object chain, say, inside an abstraction, aside from its usefulness as a GUI?
A: Yes-- see [tgl]. It takes the same [realtime] on my machine as [f]---[== 0] when the patch is not visible,
I meant: [f]x[== 0]
-Jonathan