[L2Ork-dev] Big patch takes forever to load

Ivica Ico Bukvic ico at vt.edu
Sun Dec 8 04:07:40 UTC 2013


Hi Andras,

This is very helpful. I tried to track down the problem and when I open 
your alpi_env patch with -d 3 debug option, I found out that you keep 
refreshing that array literally dozens of times per second. This tends 
to clog down the GUI that is trying to keep up with you redraws while 
trying to also keep it on the same layers as it used to be (in terms of 
drawing order), which is something regular pd ignores and therefore 
draws on top with no regard to where the array used to be drawn (so 
tofront/back completely lose meaning/purpose--as is the case in your 
abstraction where mycanvas  is in front of the array because you got 
used to the idea that array will draw on top of it, resulting in a array 
frame, then canvas, and then array contents, effectively sandwich-ing 
the mycanvas as if it exists between the two). While this in theory 
should not bog down the GUI in this case it does because the rate is 
apparently high enough to cause trouble. Now the easy solution is to 
remove processpoints subpatch that appears responsible for the bogging 
down part, because in pd-l2ork you are in theory not allowed to drag 
arrays outside the preset range, so instead of using fancy scalars, just 
use a 2-point array with a curve and you'll be done :-)

For me BTW the problem is apparent even if I open the abstraction by 
itself, likely either because my laptop is weaker or because I was 
running it with debug option which resulted in a lot of console output, 
so the problem is more pronounced.

Tkpath is apparently a bit less efficient in certain aspects but as long 
as you don't use as you put it kludge workarounds you should be ok :-)

Regarding your other abstractions, I haven't looked at them but judging 
from what you're trying to accomplish, chances are you are redrawing 
another GOP/array which is resulting in a similar problem.

Finally, regarding points and lines in an array, I discovered that in 
regular pd (or at least the one I forked from many years ago), I 
inherited inconsistency where if you created a new array as point array 
it would still draw you as a line array (or it was the other way around, 
can't remember), and where bezier array had no impact. I chose to 
simplify this and get rid of bezier array and made sure that when you 
select points at creation time you indeed get points, and when you 
select lines, you get lines.

I may want to add range limiting feature in the future which will also 
solve your problem of dragging the existing points outside the array 
range and then you could keep your fancy scalars.

Hope this helps!

On 12/06/2013 03:35 PM, András Murányi wrote:
> Hi there,
>
> lately I've been in a kind of parking position with Pd but today I 
> made some experiments and it seems I got something. I tried to remake 
> my "big patch" from scratch, adding abstractions one by one, and the 
> feeling I got is that it's getting sluggish gradually. However, when I 
> add [alpi_env] that's the moment when CPU goes 100% and the whole 
> thing gets stuck there. alpi_env.pd is a slight modification of 
> s-env.pd from an old version of s-abstractions. Note that opening 
> alpi_env.pd directly doesn't trigger the problem, only embedding it in 
> a parent patch. It used to work well until the time tkpath was 
> introduced, but of course I don't know if the problem is related to 
> tkpath or not.
>
> Some other minor observations:
> - when opening m32_mu100.pd, the vsliders update very slow when moved. 
> This is only with sliders that are routed to tabwrite (thru some other 
> objects), while an unconnected vslider updates lightning fast. And the 
> symptom only occurs when the m32_mu100.pd is opened, not when operated 
> as GOP in the parent patch.
> - still in m32_mu100.pd, arrays are displayed as curves while they 
> were saved as "display as points" (and are displayed as points in 
> pd-extended).
>
> All the mentioned patches are still in the zip at 
> http://ubuntuone.com/0RrKroD4ucd2iBVJaxnL78
>
>
> Thanks,
>
> András
>
>
> On Thu, Oct 24, 2013 at 11:46 PM, Ivica Ico Bukvic <ico at vt.edu 
> <mailto:ico at vt.edu>> wrote:
>
>     Hi Andras,
>
>     Just wanted to check if you made any progress on the ideas I
>     suggested in my last email (namely cutting a cluster of objects at
>     a time and seeing at what point the whole thing starts working
>     again and then tracing back at what point does the breakage occur).
>
>
>     On 10/21/2013 02:51 PM, András Murányi wrote:
>>
>>     On Fri, Oct 18, 2013 at 10:45 PM, Ivica Ico Bukvic <ico at vt.edu
>>     <mailto:ico at vt.edu>> wrote:
>>
>>         Andras,
>>
>>         I haven’t forgotten about your request—it is still on my TODO
>>         list. It is just that here at Virginia Tech we’re less than 2
>>         weeks away from a grand opening of a new $100M building that
>>         will house (among other things) Institute I am heavily
>>         involved in.
>>
>>
>>     Congrats!
>>
>>         As a result, I’ve been rather busy with other things. Rest
>>         assured, I will try to look into this asap. In the meantime,
>>         what would be very helpful is if you would please generate a
>>         list of all objects in the patch so that we can possibly
>>         narrow down where the problem stems from. What you’ve started
>>         doing (removing tof and mixed objects) is a great start. I
>>         have a nagging suspicion something in that patch trips up the
>>         GUI and sends an illegal command that makes GUI unresponsive.
>>         Finding out what that is will greatly help in identifying the
>>         solution. I would go as far as renaming the extra/ folder and
>>         seeing if that fixes things. If it does, then it is
>>         definitely one of the 3^rd party externals.
>>
>>
>>     I guess I could generate a list of objects from the source files
>>     using some sed/awk wizardry, but unfortunately I'm not that good
>>     at it so I'll postpone this until it eventually seems unavoidable.
>>     I have, though, renamed the whole extra/ folder and tried to open
>>     the patch once again. Minutes and minutes of 100% CPU
>>     (alternating between cores) without an ending, that is the
>>     result. It seems to me I just have too many objects for the
>>     current SVG implementation.
>>
>>         Once latter part of November rolls around, I should have a
>>         bit more time to look into this. Hope this helps!
>>
>>
>>
>>     Thanks,
>>
>>     András
>>
>>         Best wishes,
>>
>>         Ico
>>
>>         *From:*l2ork-dev-bounces at disis.music.vt.edu
>>         <mailto:l2ork-dev-bounces at disis.music.vt.edu>
>>         [mailto:l2ork-dev-bounces at disis.music.vt.edu
>>         <mailto:l2ork-dev-bounces at disis.music.vt.edu>] *On Behalf Of
>>         *András Murányi
>>         *Sent:* Friday, October 18, 2013 9:38 AM
>>         *To:* L2Ork developers
>>         *Subject:* [L2Ork-dev] Big patch takes forever to load
>>
>>         Hi Ivica,
>>
>>         I'm very interested in the recent developments involving
>>         tkzync and I can't wait to see pd-l2ork in its full zoomable,
>>         opengl glory!
>>
>>         The recent introduction of SVG drawing of object, however,
>>         posed a huge problem for me: my big patch (already posted
>>         here, http://ubuntuone.com/0RrKroD4ucd2iBVJaxnL78) just never
>>         finishes to load. This means I cannot play music unless I
>>         revert to an older version of pd-l2ork.
>>
>>         While originally I thought that the problem was caused by
>>         unaccelerated objects, removing them (by renaming the
>>         extra/tof and extra/miXed folders) doesn't seem to solve
>>         anything.
>>
>>         So at this point I'm asking for your kind advice. I would
>>         like to make use of recent pd-l2ork developments but I'm
>>         blocked by the speed drop that came with SVG rendering (I guess).
>>
>>         Thanks,
>>
>>         András
>>
>>
>>         _______________________________________________
>>         L2Ork-dev mailing list
>>         L2Ork-dev at disis.music.vt.edu
>>         <mailto:L2Ork-dev at disis.music.vt.edu>
>>         http://disis.music.vt.edu/listinfo/l2ork-dev
>>
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     L2Ork-dev mailing list
>>     L2Ork-dev at disis.music.vt.edu  <mailto:L2Ork-dev at disis.music.vt.edu>
>>     http://disis.music.vt.edu/listinfo/l2ork-dev
>
>
>     -- 
>     Ivica Ico Bukvic, D.M.A
>     Composition, Music Technology
>     Director, DISIS Interactive Sound & Intermedia Studio
>     Director, L2Ork Linux Laptop Orchestra
>     Head, ICAT IMPACT Studio
>     Virginia Tech
>     Department of Music
>     Blacksburg, VA 24061-0240
>     (540) 231-6139  <tel:%28540%29%20231-6139>
>     (540) 231-5034  <tel:%28540%29%20231-5034>  (fax)
>     disis.music.vt.edu  <http://disis.music.vt.edu>
>     l2ork.music.vt.edu  <http://l2ork.music.vt.edu>
>     ico.bukvic.net  <http://ico.bukvic.net>
>
>
>
>
> -- 
> Murányi András


-- 
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20131207/edab1d4b/attachment-0001.html>


More information about the L2Ork-dev mailing list