<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Attached is the diff for mknob.c to
make it "accelerated." Attached is also binary version of
mknob.pd_linux (64-bit) (not sure if this one will go through,
though).<br>
<br>
As for pd-l2ork being 0.42, that is not entirely correct. While
elements of GUI are still based on 0.42, many others aren't and
pd-l2ork has most if not all patches to the core pd engine
inherent to the 0.43 and 0.44 branches, including some that were
committed very recently into the sourceforge. It also has a
collection of unique patches that don't exist in any of the other
versions, so I am not even sure what one would call it other than
a pd fork :-)<br>
<br>
If you are interested in trying preset_hub and preset_node
externals they do come with a fairly comprehensive help file, so
hopefully that will help in figuring out how they function.<br>
<br>
Best wishes,<br>
<br>
Ico<br>
<br>
On 03/03/2013 09:27 PM, András Murányi wrote:<br>
</div>
<blockquote
cite="mid:CAJtGUK4rtvSctvTNg38yoZ2UtM1qGN9V0+TrUs3rKsVd4SfP5A@mail.gmail.com"
type="cite">
<div class="gmail_quote">On Mon, Mar 4, 2013 at 1:39 AM, 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:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>OK, I checked your patch and now I know why this is
happening. Allow me to explain:<br>
<br>
short (tl;dr) version: once mknob is accelerated (which
should be only a couple of lines of code inside it) this
won't be a problem any more<br>
</div>
</div>
</blockquote>
<div><br>
That will be cool.<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> <br>
For me it takes approx 3 seconds every time I move the gop
window and this solely because mknob is not accelerated
(this is on an HP dm1z AMD APU notebook/netbook).<br>
</div>
</div>
</blockquote>
<div><br>
Yes. It takes much longer in the actual patch where i use it.
At least i managed to reproduce the symptom "in vitro",<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> <br>
long version: What's happening is that pd/extended
completely redraws gop object every time it is moved. What
it does not do, is account for its location (front vs.
back) in respect to other objects when doing this. So, for
instance if you move a gop that is behind another object,
once it has been moved, it will appear in front of it
which is wrong since that is not an accurate reflection
where in the gl_list it is located. Hence, next time your
entire canvas redraws (which happens inside pd/extended at
various points), suddenly gop will be again behind the
other object. Confusing, no? Pd-l2ork in an attempt to
keep gl_list consistent always ensures that objects remain
visually stacked on top of each other in the gl_list order
no matter what operation you do. In this case, because we
have one of the few remaining gui objects that do not
support accelerated displacement (by accelerated
displacement I mean tagging such object's components in
tcl tk and then moving all objects tagged with the word
"selected" together via a single command rather than
redrawing everything), pd-l2ork falls back to the old
pd/extended way of doing things, just like pd/extended do.
It does this with one notable exception and that is to
ensure that the redrawn object remains stacked where it
should be (in terms of front/back) it also redraws the
canvas after such a drag because old way of redrawing does
not account properly for the visual order that pd-l2ork
requires. Since your patch has literally a ton of objects
pertaining to ssssad presets, this takes a while, and
hence the slowness. If you, however, put any iemgui object
instead of mknob inside that gop, the thing will be not
only fast, but also much faster than regular pd/extended.<br>
</div>
</div>
</blockquote>
<div><br>
Yea i know... i need mknob because of its so called
"sensibility" option (see mknob-help.pd).<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> <br>
So, what I can do for the next release is add support for
accelerated displacement of mknob and you'll be set.<br>
</div>
</div>
</blockquote>
<div><br>
Thanks a lot in advance!<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> <br>
Another related issue is the redundant use of hundreds of
ssssad abstractions. Pd-l2ork has system-wide
preset_hub/preset_node externals system which is easy to
use, supports use in conjunction with multiple instances
of the same abstraction (each is treated separately and
distinctly) as well as many other cool features. Think of
it as pd's counterpart to Max's pattr_storage. Their
implementation is currently possible only in pd-l2ork
since it ensures that all objects remain in the same place
in the gl_list (let's call this gl_list consistency) which
is something that regular pd/extended don't do (as
described above). So, long story short, if you use
preset_node and preset_hub you will need only one of those
to replace all of your ssssad abstractions. Pretty nifty?
;-) And that in near-term will make your canvas redrawing
much faster and consequently a non-issue.<br>
</div>
</div>
</blockquote>
<div><br>
Those hundreds of subpatches were there for dummy to make the
patch big. In real life, i use less. I am interested, however,
in other preset saving solutions. I wouldn't lock myself into
l2ork at the moment (because it's 0.42) but i'll take a look
at the preset_hub thing.<br>
<br>
Thanks again Ico!<br>
<br>
András<br>
</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>