Forgot to copy the list...
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD 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
Ivica Ico Bukvic ico@vt.edu wrote:
The said changes are in pre-git tarballs. I think they are also listed in the changelog under a specific date which should make things a bit easier to isolate. That said, implementation alters widgetbehavior struct by adding one more entry and as such it breaks compatibility with gridflow unless recompiled from scratch using the new .h file. Even then there might be other incompatibilities. That said, I've encountered none, other than gridflow. Of course, other externals need to be recompiled as well (but no changes to their source are required).
HTH
Best wishes,
Ico
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD 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
Hans-Christoph Steiner hans@at.or.at wrote:
Hey Ico,
That's great, we need to do a lot more of that. Can you point me to where these changes are so I can check them out?
.hc
On Nov 3, 2011, at 2:44 PM, Ivica Ico Bukvic wrote:
Indeed, pd-l2ork moves entire selection by tag, so instead of redrawing everything, out issues single tcl/tk command. The only thing that still redrawed every time when displaced is gop-enabled patcher.
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD 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
Jonathan Wilkes jancsika@yahoo.com wrote:
I believe Ivica made such a modification in Pd-l2ork-- whatever the case, moving many iemguis in Pd-l2ork is much snappier than in Vanilla or Pd-extended. But I haven't measured the cpu load.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: João Pais jmmmpais@googlemail.com Cc: katja katjavetter@gmail.com; "pd-list@iem.at" pd-list@iem.at; Jonathan Wilkes jancsika@yahoo.com Sent: Thursday, November 3, 2011 11:07 AM Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
I doubt that Tcl/Tk's drawing code is being overloaded. Instead, try running "path/to/pd -stderr -d 3" and you'll see that 'pd' is sending 'pd-gui' massive amounts of Tcl code to pa! rse, compile, and execute. In the case of a move, this could be accomplished with one line of Tcl to tag everything you want to move, then one move command to let Tcl/Tk do the moving.
.hc
On Nov 3, 2011, at 10:31 AM, João Pais wrote:
those spikes is what I was predicting with the graphic overloading of
tcl/tk (through data structures, in this case).
you could also try the following: make the "selectable area"
around one corner (or middle) of the button: with a tiny bit more resolution, but less points in the template. if you want to keep the squares, it's even better, because it helps you selecting the structs.
Or one other thing: maybe can the tcl/tk code be changed, so that it
doesn't overload that fast? Reduce the redraw rate, or something else? (I h! ave no idea about tcl/tk)
Or change the output rate of the struct object? (this might not help much)
About the background grid for instant jumps, an implementation of it in run
mode is easy. I could try to give an example, but don't have any time for now.
----- Original Message -----
From: katja katjavetter@gmail.com To: pd-list@iem.at Cc: Sent: Thursday, November 3, 2011 6:10 AM Subject: Re: [PD] how to capture window-related mouse-events when
toxy is discontinued?
On Thu, Nov 3, 2011 at 1:30 AM, Jonathan Wilkes
wrote:
How does the cpu usage in my demo! compare to your patch where
you use
a radiobutton?
Here's a cpu load comparison of objects dragged continuously
(on intel
mac 2GHz):
polygon in movable_box2.pd: 23 % polygon in 07.sequencer.pd (help browser): 16% radiobutton in moving_objects.pd: 12 % regular Pd slider: 13 % 2D geo in a gem window: 2.5%
I just got intermittent rises up to 50% on a dual core 64-bit amd with all of the above.
I imagine that the cpu load for movable_box2.pd is due to the number of points in the polygon. I think you could get a 20x20 draggable square
with 8 coordinates-- that
would be equal to the number of p! oints in a radiobutton so maybe that
would get down
to a corresponding cpu load.
I'll try some tweaks later to see if that works.
-Jonathan
Your polygon method is plain vanilla Pd and that makes it
attractive
for a widely shared Pd patch. No risk of broken dependencies. But I
am
afraid it is too cpu-intensive, particularly on Windows. Thanks for sharing the idea though, it is inspiring.
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmpais@googlemail.com | skype: jmmmpjmmmp
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
'You people have such restrictive dress for women,’ she said, hobbling away in ! three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
kill your television
Hey Ico,
What not just use the displacefn to do the move with tags? Then we wouldn't need to change that core struct.
.hc
Ivica Ico Bukvic ico@vt.edu wrote: The said changes are in pre-git tarballs. I think they are also listed in the changelog under a specific date which should make things a bit easier to isolate. That said, implementation alters widgetbehavior struct by adding one more entry and as such it breaks compatibility with gridflow unless recompiled from scratch using the new .h file. Even then there might be other incompatibilities. That said, I've encountered none, other than gridflow. Of course, other externals need to be recompiled as well (but no changes to their source are required).
HTH
Best wishes,
Ico
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD 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
Hans-Christoph Steiner hans@at.or.at wrote:
Hey Ico,
That's great, we need to do a lot more of that. Can you point me to where these changes are so I can check them out?
.hc
On Nov 3, 2011, at 2:44 PM, Ivica Ico Bukvic wrote:
Indeed, pd-l2ork moves entire selection by tag, so instead of redrawing everything, out issues single tcl/tk command. The only thing that still redrawed every time when displaced is gop-enabled patcher.
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD 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
Jonathan Wilkes jancsika@yahoo.com wrote: I believe Ivica made such a modification in Pd-l2ork-- whatever the case, moving many iemguis in Pd-l2ork is much snappier than in Vanilla or Pd-extended. But I haven't measured the cpu load.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: João Pais jmmmpais@googlemail.com Cc: katja katjavetter@gmail.com; "pd-list@iem.at" pd-list@iem.at; Jonathan Wilkes jancsika@yahoo.com Sent: Thursday, November 3, 2011 11:07 AM Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
I
doubt that Tcl/Tk's drawing code is being overloaded. Instead, try
running "path/to/pd -stderr -d 3" and you'll see that 'pd' is sending 'pd-gui' massive amounts of Tcl code to pa!
rse, compile, and
execute. In the case of a move, this could be accomplished with one line of Tcl to tag everything you want to move, then one move command to let Tcl/Tk do the moving.
.hc
On Nov 3, 2011, at 10:31 AM, João Pais wrote:
those spikes is what I was predicting with the graphic overloading of
tcl/tk (through data structures, in this case).
you could also try the following: make the "selectable area"
around one corner (or middle) of the button: with a tiny bit more resolution, but less points in the template. if you want to keep the squares, it's even better, because it helps you selecting the structs.
Or one other thing: maybe can the tcl/tk code be changed, so that it
doesn't overload that fast? Reduce the redraw rate, or something else? (I h!
ave no idea about tcl/tk)
Or change the output rate of the struct object? (this might not help much)
About the background grid for instant jumps, an implementation of it in run
mode is easy. I could try to give an example, but don't have any time for now.
----- Original Message -----
From: katja katjavetter@gmail.com To: pd-list@iem.at Cc: Sent: Thursday, November 3, 2011 6:10 AM Subject: Re: [PD] how to capture window-related mouse-events when
toxy is discontinued?
On Thu, Nov 3, 2011 at 1:30 AM, Jonathan Wilkes
wrote:
How does the cpu usage in my demo!
compare to your patch where
you use
a radiobutton?
Here's a cpu load comparison of objects dragged continuously
(on intel
mac 2GHz):
polygon in movable_box2.pd: 23 % polygon in 07.sequencer.pd (help browser): 16% radiobutton in moving_objects.pd: 12 % regular Pd slider: 13 % 2D geo in a gem window: 2.5%
I just got intermittent rises up to 50% on a dual core 64-bit amd with all of the above.
I imagine that the cpu load for movable_box2.pd is due to the number of points in the polygon. I think you could get a 20x20 draggable square
with 8 coordinates-- that
would be equal to the number of p!
oints in a radiobutton so maybe that
would get down
to a corresponding cpu load.
I'll try some tweaks later to see if that works.
-Jonathan
Your polygon method is plain vanilla Pd and that makes it
attractive
for a widely shared Pd patch. No risk of broken dependencies. But I
am
afraid it is too cpu-intensive, particularly on Windows. Thanks for sharing the idea though, it is inspiring.
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmpais@googlemail.com | skype: jmmmpjmmmp
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
'You people have such restrictive dress for women,’ she
said, hobbling away
in !
three inch heels and panty hose to finish out another pink-collar temp pool
day. - “Hijab Scene #2", by Mohja Kahf
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
kill your television
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Because after studying the code it looked like a difficult thing to pull off. This is because the regular displacefn is used for initial posting of objects which is absolute in nature while displacewithtag is relative, so the two dont play very nice.
HTH
Ico
From: Hans-Christoph Steiner [mailto:hans@at.or.at] Sent: Friday, November 04, 2011 6:26 PM To: Ivica Ico Bukvic Cc: pd-list@iem.at Subject: Re: [PD] how to capture window-related mouse-events when toxy isdiscontinued?
Hey Ico,
What not just use the displacefn to do the move with tags? Then we wouldn't need to change that core struct.
.hc
Ivica Ico Bukvic ico@vt.edu wrote:
The said changes are in pre-git tarballs. I think they are also listed in the changelog under a specific date which should make things a bit easier to isolate. That said, implementation alters widgetbehavior struct by adding one more entry and as such it breaks compatibility with gridflow unless recompiled from scratch using the new .h file. Even then there might be other incompatibilities. That said, I've encountered none, other than gridflow. Of course, other externals need to be recompiled as well (but no changes to their source are required).
HTH
Best wishes,
Ico
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-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/
Hans-Christoph Steiner hans@at.or.at wrote:
Hey Ico,
That's great, we need to do a lot more of that. Can you point me to where these changes are so I can check them out?
.hc
On Nov 3, 2011, at 2:44 PM, Ivica Ico Bukvic wrote:
Indeed, pd-l2ork moves entire selection by tag, so instead of redrawing everything, out issues single tcl/tk command. The only thing that still redrawed every time when displaced is gop-enabled patcher.
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-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/
Jonathan Wilkes jancsika@yahoo.com wrote:
I believe Ivica made such a modification in Pd-l2ork-- whatever the case, moving many iemguis in
Pd-l2ork is much snappier than in Vanilla or Pd-extended. But I haven't measured the cpu load.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at
To: João Pais jmmmpais@googlemail.com
Cc: katja katjavetter@gmail.com; "pd-list@iem.at" pd-list@iem.at; Jonathan Wilkes jancsika@yahoo.com
Sent: Thursday, November 3, 2011 11:07 AM
Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
I
doubt that Tcl/Tk's drawing code is being overloaded. Instead, try
running "path/to/pd -stderr -d 3" and you'll see that 'pd'
is sending 'pd-gui' massive amounts of Tcl code to pa!
rse, compile, and
execute. In the case of a move, this could be accomplished with one line of Tcl
to tag everything you want to move, then one move command to let Tcl/Tk do the
moving.
.hc
On Nov 3, 2011, at 10:31 AM, João Pais wrote:
those spikes is what I was predicting with the graphic overloading of
tcl/tk (through data structures, in this case).
you could also try the following: make the "selectable area"
around one corner (or middle) of the button: with a tiny bit more resolution,
but less points in the template. if you want to keep the squares, it's even
better, because it helps you selecting the structs.
Or one other thing: maybe can the tcl/tk code be changed, so that it
doesn't overload that fast? Reduce the redraw rate, or something else? (I
h!
ave no idea about tcl/tk)
Or change the output rate of the struct object? (this might not help much)
About the background grid for instant jumps, an implementation of it in run
mode is easy. I could try to give an example, but don't have any time for
now.
----- Original Message -----
From: katja katjavetter@gmail.com
To: pd-list@iem.at
Cc:
Sent: Thursday, November 3, 2011 6:10 AM
Subject: Re: [PD] how to capture window-related mouse-events when
toxy is discontinued?
On Thu, Nov 3, 2011 at 1:30 AM, Jonathan Wilkes
wrote:
How does the cpu usage in my demo!
compare to your patch where
you use
a radiobutton?
Here's a cpu load comparison of objects dragged continuously
(on intel
mac 2GHz):
polygon in movable_box2.pd: 23 %
polygon in 07.sequencer.pd (help browser): 16%
radiobutton in moving_objects.pd: 12 %
regular Pd slider: 13 %
2D geo in a gem window: 2.5%
I just got intermittent rises up to 50% on a dual core 64-bit amd with
all of the above.
I imagine that the cpu load for movable_box2.pd is due to the number of
points in the polygon. I think you could get a 20x20 draggable square
with 8 coordinates-- that
would be equal to the number of p!
oints in a radiobutton so maybe that
would get down
to a corresponding cpu load.
I'll try some tweaks later to see if that works.
-Jonathan
Your polygon method is plain vanilla Pd and that makes it
attractive
for a widely shared Pd patch. No risk of broken dependencies. But I
am
afraid it is too cpu-intensive, particularly on Windows. Thanks for
sharing the idea though, it is inspiring.
Katja
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
--
Friedenstr. 58
10249 Berlin (Deutschland)
Tel +49 30 42020091 | Mob +49 162 6843570
Studio +49 30 69509190
jmmmpais@googlemail.com | skype: jmmmpjmmmp
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
'You people have such restrictive dress for women, she
said, hobbling away
in !
three inch heels and panty hose to finish out another pink-collar temp pool
day. - Hijab Scene #2", by Mohja Kahf
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
kill your television
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
The problem with changing t_widgetbehavior is that it breaks binary compatibililty, I think. That makes it a pain to manage the transition. Personally, I think it'd be worthwhile to use the struct as it. Or really, I'd like to see bigger changes to offload more stuff to the GUI, like mouse motion and click handling, resizing, etc. For a resize of an object, 'pd' only needs to know about it once its done, not while its happening.
.hc
On Nov 4, 2011, at 11:36 PM, Ivica Ico Bukvic wrote:
Because after studying the code it looked like a difficult thing to pull off. This is because the regular displacefn is used for initial posting of objects which is absolute in nature while displacewithtag is relative, so the two don’t play very nice.
HTH
Ico
From: Hans-Christoph Steiner [mailto:hans@at.or.at] Sent: Friday, November 04, 2011 6:26 PM To: Ivica Ico Bukvic Cc: pd-list@iem.at Subject: Re: [PD] how to capture window-related mouse-events when toxy isdiscontinued?
Hey Ico,
What not just use the displacefn to do the move with tags? Then we wouldn't need to change that core struct.
.hc
Ivica Ico Bukvic ico@vt.edu wrote: The said changes are in pre-git tarballs. I think they are also listed in the changelog under a specific date which should make things a bit easier to isolate. That said, implementation alters widgetbehavior struct by adding one more entry and as such it breaks compatibility with gridflow unless recompiled from scratch using the new .h file. Even then there might be other incompatibilities. That said, I've encountered none, other than gridflow. Of course, other externals need to be recompiled as well (but no changes to their source are required).
HTH
Best wishes,
Ico
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD 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
Hans-Christoph Steiner hans@at.or.at wrote:
Hey Ico,
That's great, we need to do a lot more of that. Can you point me to where these changes are so I can check them out?
.hc
On Nov 3, 2011, at 2:44 PM, Ivica Ico Bukvic wrote:
Indeed, pd-l2ork moves entire selection by tag, so instead of redrawing everything, out issues single tcl/tk command. The only thing that still redrawed every time when displaced is gop-enabled patcher.
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD 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
Jonathan Wilkes jancsika@yahoo.com wrote: I believe Ivica made such a modification in Pd-l2ork-- whatever the case, moving many iemguis in
Pd-l2ork is much snappier than in Vanilla or Pd-extended. But I haven't measured the cpu load.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at
To: João Pais jmmmpais@googlemail.com
Cc: katja katjavetter@gmail.com; "pd-list@iem.at" pd-list@iem.at; Jonathan Wilkes jancsika@yahoo.com
Sent: Thursday, November 3, 2011 11:07 AM
Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
I
doubt that Tcl/Tk's drawing code is being overloaded. Instead, try
running "path/to/pd -stderr -d 3" and you'll see that 'pd'
is sending 'pd-gui' massive amounts of Tcl code to pa!
rse, compile, and
execute. In the case of a move, this could be accomplished with one line of Tcl
to tag everything you want to move, then one move command to let Tcl/Tk do the
moving.
.hc
On Nov 3, 2011, at 10:31 AM, João Pais wrote:
those spikes is what I was predicting with the graphic overloading of
tcl/tk (through data structures, in this case).
you could also try the following: make the "selectable area"
around one corner (or middle) of the button: with a tiny bit more resolution,
but less points in the template. if you want to keep the squares, it's even
better, because it helps you selecting the structs.
Or one other thing: maybe can the tcl/tk code be changed, so that it
doesn't overload that fast? Reduce the redraw rate, or something else? (I
h!
ave no idea about tcl/tk)
Or change the output rate of the struct object? (this might not help much)
About the background grid for instant jumps, an implementation of it in run
mode is easy. I could try to give an example, but don't have any time for
now.
----- Original Message -----
From: katja katjavetter@gmail.com
To: pd-list@iem.at
Cc:
Sent: Thursday, November 3, 2011 6:10 AM
Subject: Re: [PD] how to capture window-related mouse-events when
toxy is discontinued?
On Thu, Nov 3, 2011 at 1:30 AM, Jonathan Wilkes
wrote:
How does the cpu usage in my demo!
compare to your patch where
you use
a radiobutton?
Here's a cpu load comparison of objects dragged continuously
(on intel
mac 2GHz):
polygon in movable_box2.pd: 23 %
polygon in 07.sequencer.pd (help browser): 16%
radiobutton in moving_objects.pd: 12 %
regular Pd slider: 13 %
2D geo in a gem window: 2.5%
I just got intermittent rises up to 50% on a dual core 64-bit amd with
all of the above.
I imagine that the cpu load for movable_box2.pd is due to the number of
points in the polygon. I think you could get a 20x20 draggable square
with 8 coordinates-- that
would be equal to the number of p!
oints in a radiobutton so maybe that
would get down
to a corresponding cpu load.
I'll try some tweaks later to see if that works.
-Jonathan
Your polygon method is plain vanilla Pd and that makes it
attractive
for a widely shared Pd patch. No risk of broken dependencies. But I
am
afraid it is too cpu-intensive, particularly on Windows. Thanks for
sharing the idea though, it is inspiring.
Katja
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
--
Friedenstr. 58
10249 Berlin (Deutschland)
Tel +49 30 42020091 | Mob +49 162 6843570
Studio +49 30 69509190
jmmmpais@googlemail.com | skype: jmmmpjmmmp
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
'You people have such restrictive dress for women,’ she
said, hobbling away
in !
three inch heels and panty hose to finish out another pink-collar temp pool
day. - “Hijab Scene #2", by Mohja Kahf
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
kill your television
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Programs should be written for people to read, and only incidentally for machines to execute.
- from Structure and Interpretation of Computer Programs
The problem with the approach you suggested is that tcl would have to be aware of all unique redrawing properties of individual objects and externals that may require custom drawing commands. While not impossible, it would require at the very least requiring of all gui-based externals. OTOH, my approach only requires a recompile and I'd rather pick that over the alternative.
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD 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
Hans-Christoph Steiner hans@at.or.at wrote:
The problem with changing t_widgetbehavior is that it breaks binary compatibililty, I think. That makes it a pain to manage the transition. Personally, I think it'd be worthwhile to use the struct as it. Or really, I'd like to see bigger changes to offload more stuff to the GUI, like mouse motion and click handling, resizing, etc. For a resize of an object, 'pd' only needs to know about it once its done, not while its happening.
.hc
On Nov 4, 2011, at 11:36 PM, Ivica Ico Bukvic wrote:
Because after studying the code it looked like a difficult thing to pull off. This is because the regular displacefn is used for initial posting of objects which is absolute in nature while displacewithtag is relative, so the two don’t play very nice.
HTH
Ico
From: Hans-Christoph Steiner [mailto:hans@at.or.at] Sent: Friday, November 04, 2011 6:26 PM To: Ivica Ico Bukvic Cc: pd-list@iem.at Subject: Re: [PD] how to capture window-related mouse-events when toxy isdiscontinued?
Hey Ico,
What not just use the displacefn to do the move with tags? Then we wouldn't need to change that core struct.
.hc
Ivica Ico Bukvic ico@vt.edu wrote: The said changes are in pre-git tarballs. I think they are also listed in the changelog under a specific date which should make things a bit easier to isolate. That said, implementation alters widgetbehavior struct by adding one more entry and as such it breaks compatibility with gridflow unless recompiled from scratch using the new .h file. Even then there might be other incompatibilities. That said, I've encountered none, other than gridflow. Of course, other externals need to be recompiled as well (but no changes to their source are required).
HTH
Best wishes,
Ico
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD 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
Hans-Christoph Steiner hans@at.or.at wrote:
Hey Ico,
That's great, we need to do a lot more of that. Can you point me to where these changes are so I can check them out?
.hc
On Nov 3, 2011, at 2:44 PM, Ivica Ico Bukvic wrote:
Indeed, pd-l2ork moves entire selection by tag, so instead of redrawing everything, out issues single tcl/tk command. The only thing that still redrawed every time when displaced is gop-enabled patcher.
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD 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
Jonathan Wilkes jancsika@yahoo.com wrote: I believe Ivica made such a modification in Pd-l2ork-- whatever the case, moving many iemguis in
Pd-l2ork is much snappier than in Vanilla or Pd-extended. But I haven't measured the cpu load.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at
To: João Pais jmmmpais@googlemail.com
Cc: katja katjavetter@gmail.com; "pd-list@iem.at" pd-list@iem.at; Jonathan Wilkes jancsika@yahoo.com
Sent: Thursday, November 3, 2011 11:07 AM
Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
I
doubt that Tcl/Tk's drawing code is being overloaded. Instead, try
running "path/to/pd -stderr -d 3" and you'll see that 'pd'
is sending 'pd-gui' massive amounts of Tcl code to pa!
rse, compile, and
execute. In the case of a move, this could be accomplished with one line of Tcl
to tag everything you want to move, then one move command to let Tcl/Tk do the
moving.
.hc
On Nov 3, 2011, at 10:31 AM, João Pais wrote:
those spikes is what I was predicting with the graphic overloading of
tcl/tk (through data structures, in this case).
you could also try the following: make the "selectable area"
around one corner (or middle) of the button: with a tiny bit more resolution,
but less points in the template. if you want to keep the squares, it's even
better, because it helps you selecting the structs.
Or one other thing: maybe can the tcl/tk code be changed, so that it
doesn't overload that fast? Reduce the redraw rate, or something else? (I
h!
ave no idea about tcl/tk)
Or change the output rate of the struct object? (this might not help much)
About the background grid for instant jumps, an implementation of it in run
mode is easy. I could try to give an example, but don't have any time for
now.
----- Original Message -----
From: katja katjavetter@gmail.com
To: pd-list@iem.at
Cc:
Sent: Thursday, November 3, 2011 6:10 AM
Subject: Re: [PD] how to capture window-related mouse-events when
toxy is discontinued?
On Thu, Nov 3, 2011 at 1:30 AM, Jonathan Wilkes
wrote:
How does the cpu usage in my demo!
compare to your patch where
you use
a radiobutton?
Here's a cpu load comparison of objects dragged continuously
(on intel
mac 2GHz):
polygon in movable_box2.pd: 23 %
polygon in 07.sequencer.pd (help browser): 16%
radiobutton in moving_objects.pd: 12 %
regular Pd slider: 13 %
2D geo in a gem window: 2.5%
I just got intermittent rises up to 50% on a dual core 64-bit amd with
all of the above.
I imagine that the cpu load for movable_box2.pd is due to the number of
points in the polygon. I think you could get a 20x20 draggable square
with 8 coordinates-- that
would be equal to the number of p!
oints in a radiobutton so maybe that
would get down
to a corresponding cpu load.
I'll try some tweaks later to see if that works.
-Jonathan
Your polygon method is plain vanilla Pd and that makes it
attractive
for a widely shared Pd patch. No risk of broken dependencies. But I
am
afraid it is too cpu-intensive, particularly on Windows. Thanks for
sharing the idea though, it is inspiring.
Katja
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
--
Friedenstr. 58
10249 Berlin (Deutschland)
Tel +49 30 42020091 | Mob +49 162 6843570
Studio +49 30 69509190
jmmmpais@googlemail.com | skype: jmmmpjmmmp
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
'You people have such restrictive dress for women,’ she
said, hobbling away
in !
three inch heels and panty hose to finish out another pink-collar temp pool
day. - “Hijab Scene #2", by Mohja Kahf
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
That is true, it is an easier change from the point of view of updating GUI externals.
I think we should really be looking at the whole GUI object API as a whole and redoing it so that Tcl handles a lot more of the stuff it does really easily. Things like handling cursor changes, mouse motion and clicks, tagging and moving, etc. This would inevitably mean a new API for writing GUI objects. My work towards this goal is in tkwidgets and the filterview object, its far from complete, but a solid start, here's the code:
https://github.com/pd-projects/filterview https://github.com/pd-projects/tkwidgets (specifically the 'newentry' branch).
.hc
On Nov 5, 2011, at 11:53 AM, Ivica Ico Bukvic wrote:
The problem with the approach you suggested is that tcl would have to be aware of all unique redrawing properties of individual objects and externals that may require custom drawing commands. While not impossible, it would require at the very least requiring of all gui-based externals. OTOH, my approach only requires a recompile and I'd rather pick that over the alternative.
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD 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
Hans-Christoph Steiner hans@at.or.at wrote:
The problem with changing t_widgetbehavior is that it breaks binary compatibililty, I think. That makes it a pain to manage the transition. Personally, I think it'd be worthwhile to use the struct as it. Or really, I'd like to see bigger changes to offload more stuff to the GUI, like mouse motion and click handling, resizing, etc. For a resize of an object, 'pd' only needs to know about it once its done, not while its happening.
.hc
On Nov 4, 2011, at 11:36 PM, Ivica Ico Bukvic wrote:
Because after studying the code it looked like a difficult thing to pull off. This is because the regular displacefn is used for initial posting of objects which is absolute in nature while displacewithtag is relative, so the two don’t play very nice.
HTH
Ico
From: Hans-Christoph Steiner
[mailto:hans@at.or.at]
Sent: Friday, November 04, 2011 6:26 PM To: Ivica Ico Bukvic Cc: pd-list@iem.at Subject: Re: [PD] how to capture window-related mouse-events when toxy isdiscontinued?
Hey Ico,
What not just use the displacefn to do the move with tags? Then we wouldn't need to change that core struct.
.hc
Ivica Ico Bukvic ico@vt.edu wrote: The said changes are in pre-git tarballs. I think they are also listed in the changelog under a specific date which should make things a bit easier to isolate. That said, implementation alters widgetbehavior struct by adding one more entry and as such it breaks compatibility with gridflow unless recompiled from scratch using the new .h file. Even then there might be other incompatibilities. That said, I've encountered none, other than gridflow. Of course, other externals need t!
o be recompiled as well (but no changes to their source are required).
HTH
Best wishes,
Ico
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD 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
Hans-Christoph Steiner hans@at.or.at wrote:
Hey Ico,
That's great, we need to do a lot more of that. Can you point me to where these changes are so I can check them out?
.hc
On Nov 3, 2011, at 2:44 PM, Ivica Ico Bukvic wrote:
Indeed, pd-l2ork moves entire selection by tag, so instead of redrawing everything, out issues single tcl/tk command. The only thing that still redrawed every time when displaced is gop-enabled patcher.
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD 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
Jonathan Wilkes jancsika@yahoo.com wrote: I bel!
ieve Ivica made such a modification in Pd-l2ork-- whatever the case, moving many iemguis in
Pd-l2ork is much snappier than in Vanilla or Pd-extended. But I haven't measured the cpu load.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at
To: João Pais jmmmpais@googlemail.com
Cc: katja katjavetter@gmail.com; "pd-list@iem.at" pd-list@iem.at; Jonathan Wilkes jancsika@yahoo.com
Sent: Thursday, November 3, 2011 11:07 AM
Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
I
doubt that Tcl/Tk's drawing code is being overloaded. Instead!
, try
running "path/to/pd -stderr -d 3" and you'll see that 'pd'
is sending 'pd-gui' massive amounts of Tcl code to pa!
rse, compile, and
execute. In the case of a move, this could be accomplished with one line of Tcl
to tag everything you want to move, then one move command to let Tcl/Tk do the
moving.
.hc
On Nov 3, 2011, at 10:31 AM, João Pais wrote:
those spikes is what I was predicting with the graphic overloading of
tcl/tk (through data structures, in this case).
you could also try the following: make the "selectable area"
around one corner (or m!
iddle) of the button: with a tiny bit more resolution,
but less points in the template. if you want to keep the squares, it's even
better, because it helps you selecting the structs.
Or one other thing: maybe can the tcl/tk code be changed, so that it
doesn't overload that fast? Reduce the redraw rate, or something else? (I
h!
ave no idea about tcl/tk)
Or change the output rate of the struct object? (this might not help much)
About the background grid for instant jumps, an implementation of it in run
mode is easy. I could try to give an example, but don't have any time for
now.
----- Original Message -----
From: katja katjavetter@gmail.com
To: pd-list@iem.at
Cc:
Sent: Thursday, November 3, 2011 6:10 AM
Subject: Re: [PD] how to capture window-related mouse-events when
toxy is discontinued?
On Thu, Nov 3, 2011 at 1:30 AM, Jonathan Wilkes
wrote:
> How does the cpu usage in my demo!
compare to your patch where
you use
a radiobutton?
Here's a cpu load comparison of objects dragged continuously
(on intel
mac 2GHz):
polygon in movable_box2.pd: 23 %
polygon in 07.sequencer.pd (help browser): 16%
radiobutton in moving_objects.pd: 12 %
regular Pd slider: 13 %
2D geo in a gem window: 2.5%
I just got intermittent rises up to 50% on a dual core 64-bit amd with
all of the above.
I imagine that the cpu load for movable_box2.pd is due t!
o the number of
points in the polygon. I think you could get a 20x20 draggable square
with 8 coordinates-- that
would be equal to the number of p!
oints in a radiobutton so maybe that
would get down
to a corresponding cpu load.
I'll try some tweaks later to see if that works.
-Jonathan
Your polygon method is plain vanilla Pd and that makes it
attractive
for a widely shared Pd patch. No risk of broken dependencies. But I
am
af!
raid it is too cpu-intensive, particularly on Windows. Thanks for
sharing the idea though, it is inspiring.
Katja
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
--
Friedenstr. 58
10249 Berlin (Deutschland)
Tel +49 30 42020091 | Mob +49 162 6843570
Studio +49 30 69509190
jmmmpais@googlemail.com | skype: jmmmpjmmmp
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
'You people have such restrictive dress for women,’ she
said, hobbling away
in !
three inch heels and panty hose to finish out another pink-collar temp pool
day. - “Hijab Scene #2", by Mohja Kahf
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
“We must become the change we want to see. - Mahatma Gandhi
Le 2011-11-05 à 00:50:00, Hans-Christoph Steiner a écrit :
The problem with changing t_widgetbehavior is that it breaks binary compatibililty, I think.
Yes, and I already had made extra-crunchy hacks in GridFlow so that it can be binary-compatible with both Vanilla and Extended while doing m_imp.h hacks. This was because Extended introduced the quite unnecessary m_blobmethod field.
So, I'd have to do another hack like that (but easier) to support L2Ork. I'm not interested in distributing more binaries, so either Ivica distributes his own GridFlow binaries, or preferably, I would have some code to auto-detect L2Ork and act accordingly.
Coïncidentally, both binary-compat problems have to do with (different parts of) the comment-inlet hack used in the GFDP helpfile «template».
There are similar binary-compat problems trying to deal with multiple versions of Extended because GridFlow also links to GEM, which comes in multiple binary-incompatible versions depending on the version of Extended.
GF supports 3 different ABIs of GEM, but now there's a new ABI that it isn't compatible with yet. It's the 3rd different GEM ABI to be labelled «0.93» so far. (but I don't remember which versions of GEM are bundled with Extended).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Nov 5, 2011, at 12:47 PM, Mathieu Bouchard wrote:
Le 2011-11-05 à 00:50:00, Hans-Christoph Steiner a écrit :
The problem with changing t_widgetbehavior is that it breaks binary compatibililty, I think.
Yes, and I already had made extra-crunchy hacks in GridFlow so that it can be binary-compatible with both Vanilla and Extended while doing m_imp.h hacks. This was because Extended introduced the quite unnecessary m_blobmethod field.
So, I'd have to do another hack like that (but easier) to support L2Ork. I'm not interested in distributing more binaries, so either Ivica distributes his own GridFlow binaries, or preferably, I would have some code to auto-detect L2Ork and act accordingly.
Coïncidentally, both binary-compat problems have to do with (different parts of) the comment-inlet hack used in the GFDP helpfile «template».
There are similar binary-compat problems trying to deal with multiple versions of Extended because GridFlow also links to GEM, which comes in multiple binary-incompatible versions depending on the version of Extended.
GF supports 3 different ABIs of GEM, but now there's a new ABI that it isn't compatible with yet. It's the 3rd different GEM ABI to be labelled «0.93» so far. (but I don't remember which versions of GEM are bundled with Extended).
Is that a Pd-extended issue or a Gem issue? I don't really know much about Gem's guts or C++ linking. I was under the impression this issue is related to C++ name mangling.
.hc
"Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder." - Chris McCormick
Le 2011-11-05 à 22:32:00, Hans-Christoph Steiner a écrit :
On Nov 5, 2011, at 12:47 PM, Mathieu Bouchard wrote:
GF supports 3 different ABIs of GEM, but now there's a new ABI that it isn't compatible with yet. It's the 3rd different GEM ABI to be labelled «0.93» so far. (but I don't remember which versions of GEM are bundled with Extended).
Is that a Pd-extended issue or a Gem issue?
I mention one of the GEM linkage problems as a different example of the same kind of problem.
I don't really know much about Gem's guts or C++ linking. I was under the impression this issue is related to C++ name mangling.
Well, I have two problems with linking with GEM :
One is that the GEM ABI keeps changing (struct fields get added and deleted in header files needed to support GEM).
The other is that VisualC++'s ABI is not compatible with GCC's C++ ABI, and that makes it impossible to use [#to_pix] and [#from_pix] on Windows. It's both the name mangling and the exception-handling, but I got stuck at the name-mangling part.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-04 à 23:36:00, Ivica Ico Bukvic a écrit :
Because after studying the code it looked like a difficult thing to pull off. This is because the regular displacefn is used for initial posting of objects which is absolute in nature while displacewithtag is relative, so the two don’t play very nice.
My experience with t_widgetbehavior and reading IEMGUI code is that the API is not designed to match what implementors really need to say about their own GUI objects.
E.g. if each object uses two tags per canvas item, one of which is common to every item in the object, then Pd can tell Tk to delete all items of that object, and then t_deletefn needs not be implemented at all. (Desiredata works like that)
There are other things like that, so that in the end, the number of methods to be implemented is more like 2, rather than 7 or 8.
BTW, IEMGUI code is not a good example, but it's nearly the only one we have (most other GUI externals imitate them in some way). IEMGUI defines its own t_widgetbehavior-like thing using an enum IEM_GUI_DRAW_MODE_stuff and a single function-pointer. It didn't need to work like that. So, when reading that code, you have to imagine what it would have looked like if it had been using t_widgetbehavior in a straightforward way, before you can analyse it as an example of use of t_widgetbehavior.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-
Hans-Christoph Steiner -
Ivica Ico Bukvic -
Mathieu Bouchard