[PD] pd-l2ork feedback
Ivica Ico Bukvic
ico at vt.edu
Mon Mar 4 05:02:01 CET 2013
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).
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 :-)
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.
Best wishes,
Ico
On 03/03/2013 09:27 PM, András Murányi wrote:
> On Mon, Mar 4, 2013 at 1:39 AM, Ivica Ico Bukvic <ico at vt.edu
> <mailto: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
--
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://lists.puredata.info/pipermail/pd-list/attachments/20130303/49aa9f16/attachment-0001.htm>
-------------- next part --------------
--- ../../../pd-extended/pd-svn/externals/moonlib/mknob.c 2012-11-22 13:50:00.430123507 -0500
+++ mknob.c 2013-03-03 22:56:07.031865870 -0500
@@ -113,19 +113,19 @@
int yc=ypos+x->x_gui.x_w/2;
t_canvas *canvas=glist_getcanvas(glist);
- sys_vgui(".x%lx.c create oval %d %d %d %d -fill #%6.6x -tags %xBASE\n",
+ sys_vgui(".x%lx.c create oval %d %d %d %d -fill #%6.6x -tags {%xBASE %xMKNOB}\n",
canvas,xpos,ypos,xpos + x->x_gui.x_w, ypos + x->x_gui.x_w,
- x->x_gui.x_bcol,x);
- sys_vgui(".x%lx.c create polygon %d %d %d %d %d %d -fill #%6.6x -tags %xKNOB\n",
+ x->x_gui.x_bcol, x, x);
+ sys_vgui(".x%lx.c create polygon %d %d %d %d %d %d -fill #%6.6x -tags {%xKNOB %xMKNOB}\n",
glist_getcanvas(glist),
- xc,ypos,xc-4,yc,xc+4,yc,x->x_gui.x_fcol,x);
+ xc,ypos,xc-4,yc,xc+4,yc,x->x_gui.x_fcol,x,x);
mknob_update_knob(x,glist);
sys_vgui(".x%lx.c create text %d %d -text {%s} -anchor w \
- -font {{%s} %d bold} -fill #%6.6x -tags %xLABEL\n",
+ -font {{%s} %d bold} -fill #%6.6x -tags {%xLABEL %xMKNOB}\n",
canvas, xpos+x->x_gui.x_ldx,
ypos+x->x_gui.x_ldy,
strcmp(x->x_gui.x_lab->s_name, "empty")?x->x_gui.x_lab->s_name:"",
- x->x_gui.x_font, x->x_gui.x_fontsize, x->x_gui.x_lcol, x);
+ x->x_gui.x_font, x->x_gui.x_fontsize, x->x_gui.x_lcol, x, x);
/*if(!x->x_gui.x_fsf.x_snd_able)
sys_vgui(".x%lx.c create rectangle %d %d %d %d -tags %xOUT%d\n",
canvas, xpos+ x->x_gui.x_w/2-3, ypos + x->x_gui.x_w-1,
@@ -216,12 +216,14 @@
//pd_bind(&x->x_gui.x_obj.ob_pd, iemgui_key_sym);
sys_vgui(".x%lx.c itemconfigure %xBASE -outline #%6.6x\n", canvas, x, IEM_GUI_COLOR_SELECTED);
sys_vgui(".x%lx.c itemconfigure %xLABEL -fill #%6.6x\n", canvas, x, IEM_GUI_COLOR_SELECTED);
+ sys_vgui(".x%lx.c addtag selected withtag %lxMKNOB\n", canvas, x);
}
else
{
//pd_unbind(&x->x_gui.x_obj.ob_pd, iemgui_key_sym);
sys_vgui(".x%lx.c itemconfigure %xBASE -outline #%6.6x\n", canvas, x, IEM_GUI_COLOR_NORMAL);
sys_vgui(".x%lx.c itemconfigure %xLABEL -fill #%6.6x\n", canvas, x, x->x_gui.x_lcol);
+ sys_vgui(".x%lx.c dtag %lxMKNOB selected\n", canvas, x);
}
}
@@ -872,6 +874,9 @@
iemgui_key_sym = gensym("#keyname");*/
mknob_widgetbehavior.w_getrectfn = mknob_getrect;
mknob_widgetbehavior.w_displacefn = iemgui_displace;
+#ifdef PDL2ORK
+ mknob_widgetbehavior.w_displacefnwtag = iemgui_displace_withtag;
+#endif
mknob_widgetbehavior.w_selectfn = iemgui_select;
mknob_widgetbehavior.w_activatefn = NULL;
mknob_widgetbehavior.w_deletefn = iemgui_delete;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mknob.pd_linux
Type: application/octet-stream
Size: 62662 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130303/49aa9f16/attachment-0001.obj>
More information about the Pd-list
mailing list