[PD] pd-l2ork feedback

András Murányi muranyia at gmail.com
Mon Mar 4 03:27:01 CET 2013


On Mon, Mar 4, 2013 at 1:39 AM, Ivica Ico Bukvic <ico at vt.edu> wrote:

>  OK, I checked your patch and now I know why this is happening. Allow me
> to explain:
>
> 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
>

That will be cool.


>
> 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).
>

Yes. It takes much longer in the actual patch where i use it. At least i
managed to reproduce the symptom "in vitro",


>
> 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.
>

Yea i know... i need mknob because of its so called "sensibility" option
(see mknob-help.pd).


>
> So, what I can do for the next release is add support for accelerated
> displacement of mknob and you'll be set.
>

Thanks a lot in advance!


>
> 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.
>

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.

Thanks again Ico!

András
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130304/e7042279/attachment.htm>


More information about the Pd-list mailing list