<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Andras,<br>
<br>
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 :-)<br>
<br>
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.<br>
<br>
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 :-)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Hope this helps!<br>
<br>
On 12/06/2013 03:35 PM, András Murányi wrote:<br>
</div>
<blockquote
cite="mid:CAJtGUK7ydKyVVt6-bfswOm73sARM++mA3QqRuP3ceAGEMEYwcA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">Hi there,<br>
<br>
</div>
<div class="gmail_extra">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.<br>
<br>
</div>
<div class="gmail_extra">Some other minor observations:<br>
</div>
<div class="gmail_extra">- 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.<br>
</div>
<div class="gmail_extra">- 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).<br>
</div>
<div class="gmail_extra">
<br>
All the mentioned patches are still in the zip at <a
moz-do-not-send="true"
href="http://ubuntuone.com/0RrKroD4ucd2iBVJaxnL78"
target="_blank">http://ubuntuone.com/0RrKroD4ucd2iBVJaxnL78</a><br>
<br>
<br>
</div>
<div class="gmail_extra">Thanks,<br>
<br>
</div>
<div class="gmail_extra">
András<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Oct 24, 2013 at 11:46 PM,
Ivica Ico Bukvic <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:ico@vt.edu"
target="_blank">ico@vt.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hi Andras,<br>
<br>
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).
<div>
<div><br>
<br>
On 10/21/2013 02:51 PM, András Murányi wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Oct 18, 2013
at 10:45 PM, Ivica Ico Bukvic <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div link="blue" vlink="purple"
lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Andras,</span></p>
<p class="MsoNormal"> <span
style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">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.</span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Congrats!<br>
</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div link="blue" vlink="purple"
lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">
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<sup>rd</sup>
party externals.</span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.<br>
</div>
<div>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.<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div link="blue" vlink="purple"
lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"></span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Once
latter part of November rolls
around, I should have a bit more
time to look into this. Hope this
helps!</span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"><br>
</span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Thanks,<br>
<br>
András<br>
<br>
</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div link="blue" vlink="purple"
lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"></span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Best
wishes,</span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Ico</span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"> </span></p>
<div style="border-width:medium medium
medium 1.5pt;border-style:none none
none
solid;border-color:-moz-use-text-color
-moz-use-text-color
-moz-use-text-color blue;padding:0in
0in 0in 4pt">
<div>
<div style="border-width:1pt
medium medium;border-style:solid
none
none;border-color:rgb(181,196,223)
-moz-use-text-color
-moz-use-text-color;padding:3pt
0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10pt;font-family:"Tahoma","sans-serif"">
<a moz-do-not-send="true"
href="mailto:l2ork-dev-bounces@disis.music.vt.edu"
target="_blank">l2ork-dev-bounces@disis.music.vt.edu</a>
[mailto:<a
moz-do-not-send="true"
href="mailto:l2ork-dev-bounces@disis.music.vt.edu"
target="_blank">l2ork-dev-bounces@disis.music.vt.edu</a>]
<b>On Behalf Of </b>András
Murányi<br>
<b>Sent:</b> Friday, October
18, 2013 9:38 AM<br>
<b>To:</b> L2Ork developers<br>
<b>Subject:</b> [L2Ork-dev]
Big patch takes forever to
load</span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"
style="margin-bottom:12pt">Hi Ivica,</p>
</div>
<p class="MsoNormal">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!</p>
</div>
<p class="MsoNormal">The
recent introduction of
SVG drawing of object,
however, posed a huge
problem for me: my big
patch (already posted
here, <a
moz-do-not-send="true"
href="http://ubuntuone.com/0RrKroD4ucd2iBVJaxnL78" target="_blank">http://ubuntuone.com/0RrKroD4ucd2iBVJaxnL78</a>)
just never finishes to
load. This means I
cannot play music
unless I revert to an
older version of
pd-l2ork.</p>
</div>
<p class="MsoNormal">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.</p>
</div>
<p class="MsoNormal"
style="margin-bottom:12pt">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).</p>
</div>
<p class="MsoNormal">Thanks,<br
clear="all">
</p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<p
class="MsoNormal">András
</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:L2Ork-dev@disis.music.vt.edu"
target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a moz-do-not-send="true"
href="http://disis.music.vt.edu/listinfo/l2ork-dev"
target="_blank">http://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
L2Ork-dev mailing list
<a moz-do-not-send="true" href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a>
<a moz-do-not-send="true" href="http://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">http://disis.music.vt.edu/listinfo/l2ork-dev</a></pre>
</blockquote>
<br>
<br>
</div>
</div>
<pre cols="72">--
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
<a moz-do-not-send="true" href="tel:%28540%29%20231-6139" value="+15402316139" target="_blank">(540) 231-6139</a>
<a moz-do-not-send="true" href="tel:%28540%29%20231-5034" value="+15402315034" target="_blank">(540) 231-5034</a> (fax)
<a moz-do-not-send="true" href="http://disis.music.vt.edu" target="_blank">disis.music.vt.edu</a>
<a moz-do-not-send="true" href="http://l2ork.music.vt.edu" target="_blank">l2ork.music.vt.edu</a>
<a moz-do-not-send="true" href="http://ico.bukvic.net" target="_blank">ico.bukvic.net</a></pre>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Murányi András
</div>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
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</pre>
</body>
</html>