Hello,
It happens to be the case that mouse-event capturing as done by [toxy/tot] is crucial to my Pd performance setups. The object gives xy positions relative to a window, not to the screen(s). These coordinates are used to move GUI's around on a large xy-field, like a multiple-control Kaoss Pad. Specially useful in combination with touchscreen. Here's one clip illustrating the concept:
http://www.youtube.com/user/instantdecomposer#p/a/u/2/Qo1CwYxmplE
The toxy lib is discontinued in Pd-extended 0.43. Tried to find an alternative, asked on the Pd forum. No solution so far. I explored gem for GUI purposes, but this introduces even more dependencies. Data-structures seem an option at first sight, but can not provide large reactive area's (only the center pixel of an object is reactive). Good old [MouseState] doesn't know where the window is. In a brief moment of optimism, I even considered taking up maintaince of toxy, but the code is total hocus pocus to me.
In the meantime, one of those live-perfo tools, Slice//Jockey, has started to spread around the world and is being used by some performers and composers. As you may understand, I am particularly concerned to provide a 0.43-compatible version as soon as possible. Any help to find a window-related mouse-capturing method, working in 0.42 and 0.43 alike, is very much appreciated.
Katja
Le 2011-11-02 à 15:24:00, katja a écrit :
It happens to be the case that mouse-event capturing as done by [toxy/tot] is crucial to my Pd performance setups. The object gives xy positions relative to a window, not to the screen(s).
http://gridflow.ca/help/gf/mouse_spy-help.html
The toxy lib is discontinued in Pd-extended 0.43.
However, there are still problems loading GridFlow in pd-extended 43.
I bet Toxy is not far from working with pd-extended 43. I don't recall hearing the reasons for removing it. Seems quite unilateral.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Nov 2, 2011, at 10:39 AM, Mathieu Bouchard wrote:
Le 2011-11-02 à 15:24:00, katja a écrit :
It happens to be the case that mouse-event capturing as done by [toxy/tot] is crucial to my Pd performance setups. The object gives xy positions relative to a window, not to the screen(s).
[hcs/cursor]
The toxy lib is discontinued in Pd-extended 0.43.
However, there are still problems loading GridFlow in pd-extended 43.
I bet Toxy is not far from working with pd-extended 43. I don't recall hearing the reasons for removing it. Seems quite unilateral.
I don't have time to work on it anymore. Anyone else is welcome to.
.hc
http://at.or.at/hans/
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: katja katjavetter@gmail.com Cc: pd-list@iem.at Sent: Wednesday, November 2, 2011 10:39 AM Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
Le 2011-11-02 à 15:24:00, katja a écrit :
It happens to be the case that mouse-event capturing as done by [toxy/tot] is crucial to my Pd performance setups. The object gives xy positions relative to a window, not to the screen(s).
http://gridflow.ca/help/gf/mouse_spy-help.html
The toxy lib is discontinued in Pd-extended 0.43.
However, there are still problems loading GridFlow in pd-extended 43.
I bet Toxy is not far from working with pd-extended 43. I don't recall hearing the reasons for removing it. Seems quite unilateral.
One thing is that any GUI objects created with [widget] cease to pass messages when the containing window gets unmapped. At least I think that was the case. I think there were some other problems with [widget] as well, but at the moment I don't remember any problems with [tot].
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2011-11-02 à 08:19:00, Jonathan Wilkes a écrit :
One thing is that any GUI objects created with [widget] cease to pass messages when the containing window gets unmapped.
Is that a problem...? What problem does that cause ?
Anyway, Pd does weird things with unmapped window... It deletes all canvas-items whenever you minimise a window. I don't know whether it was ever useful to save RAM back in 1995 when 16M would cost between 640 $ and 2000 $ (remember the RAM shortage racket ?), but this behaviour is part of Pd, and you have to take into account, whether you use t_widgetbehavior or Toxy.
I don't remember whether DesireData preserved that behaviour, but it's possible that I didn't bother changing that (however, DD introduced additional layers so that C code would hardly know what Tk is).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: katja katjavetter@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Saturday, November 5, 2011 10:41 AM Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
Le 2011-11-02 à 08:19:00, Jonathan Wilkes a écrit :
One thing is that any GUI objects created with [widget] cease to pass
messages when the containing window gets unmapped.
Is that a problem...? What problem does that cause ?
Well, if you threw a [tgl] into a subpatch or abstraction, got the object chain that it's in working, then closed that window and the [tgl] no longer passes messages, it is extremely likely that your patch will no longer work.
Granted one might be less likely to be embedding [widget] objects where they won't be seen, but that requirement limits their usefulness. For example, I can send a "set" message to a [tgl], or change its color when it's unmapped-- not only can I not do that with [widget], but I'll get an error if I try.
At least that's what I remember the last time I used [widget]. It also didn't [loadbang] properly which was annoying.
-Jonathan
Anyway, Pd does weird things with unmapped window... It deletes all canvas-items whenever you minimise a window. I don't know whether it was ever useful to save RAM back in 1995 when 16M would cost between 640 $ and 2000 $ (remember the RAM shortage racket ?), but this behaviour is part of Pd, and you have to take into account, whether you use t_widgetbehavior or Toxy.
I don't remember whether DesireData preserved that behaviour, but it's possible that I didn't bother changing that (however, DD introduced additional layers so that C code would hardly know what Tk is).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-05 à 08:20:00, Jonathan Wilkes a écrit :
Well, if you threw a [tgl] into a subpatch or abstraction, got the object chain that it's in working, then closed that window and the [tgl] no longer passes messages, it is extremely likely that your patch will no longer work.
Ok, you mean how [tgl] also does something without a GUI ?
That's because many GUI objects aren't « purely GUI objects », whereas Toxy allows you only to make GUI objects. This means that you have to wrap nearly every use of Toxy inside some kind of abstraction, in order to provide the extra features.
It's not the best way to say it, though, because for example, most methods of IEMGUI are for configuring GUI stuff such as colour and font size. Instead, let's say that anything that you still want to work with -nogui has to be implemented like that, and that principle also happens to apply to closed subpatches, closed abstr-instances, ever and minimised windows.
At least that's what I remember the last time I used [widget]. It also didn't [loadbang] properly which was annoying.
The concept of [widget] is interesting, but I think that it needs to be redone in some other way. Just like all the GUI.
At this point, though, my opinion on how to do it has changed significantly since the DD days, which is part of why I don't especially want to finish DD (and this change of opinion also has to do with persistent patterns in bugs I encountered).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: katja katjavetter@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Saturday, November 5, 2011 12:11 PM Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
Le 2011-11-05 à 08:20:00, Jonathan Wilkes a écrit :
Well, if you threw a [tgl] into a subpatch or abstraction, got the object
chain that it's in working, then closed that window and the [tgl] no longer passes messages, it is extremely likely that your patch will no longer work.
Ok, you mean how [tgl] also does something without a GUI ?
That's because many GUI objects aren't « purely GUI objects », whereas Toxy allows you only to make GUI objects. This means that you have to wrap nearly every use of Toxy inside some kind of abstraction, in order to provide the extra features.
It's not the best way to say it, though, because for example, most methods of IEMGUI are for configuring GUI stuff such as colour and font size. Instead, let's say that anything that you still want to work with -nogui has to be implemented like that, and that principle also happens to apply to closed subpatches, closed abstr-instances, ever and minimised windows.
I haven't worked much with the -nogui flag, but what's wrong with sending a [size 20( message to [tgl] in nogui mode? I don't see an error message.
At least that's what I remember the last time I used [widget]. It also
didn't [loadbang] properly which was annoying.
The concept of [widget] is interesting, but I think that it needs to be redone in some other way. Just like all the GUI.
I think they are two different levels of "needs to be redone"-- iemguis could be better but are consistent and functional. [widget] is buggy, a bit confusing*, and inconsistent with most other gui objects.
- it's not actually tcl syntax, btw
At this point, though, my opinion on how to do it has changed significantly since the DD days, which is part of why I don't especially want to finish DD (and this change of opinion also has to do with persistent patterns in bugs I encountered).
Ah, ok-- then I won't bug you about DD. :)
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-05 à 09:50:00, Jonathan Wilkes a écrit :
I haven't worked much with the -nogui flag, but what's wrong with sending a [size 20( message to [tgl] in nogui mode? I don't see an error message.
It's not «wrong», it's just that Toxy implements only the t_widgetbehavior/sys_vgui part of it, and you have to code the rest of the class by other means, e.g. as an abstraction wrapper. I don't know what's written in Toxy's docs (never really used it), but it sounds clear from the description of the problem that the problem is that you have to use an abstraction around most uses of Toxy, while you assume that you don't have to.
- it's not actually tcl syntax, btw
Yeah... that's a normal problem in Pd.
Ah, ok-- then I won't bug you about DD. :)
Well, we could talk about future replacements to DD instead.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-02 15:24, katja wrote:
Hello,
It happens to be the case that mouse-event capturing as done by [toxy/tot] is crucial to my Pd performance setups.
iemguts' [receivecanvas] might help you.
fgmasdr IOhannes
On Nov 2, 2011, at 10:24 AM, katja wrote:
Hello,
It happens to be the case that mouse-event capturing as done by [toxy/tot] is crucial to my Pd performance setups. The object gives xy positions relative to a window, not to the screen(s). These coordinates are used to move GUI's around on a large xy-field, like a multiple-control Kaoss Pad. Specially useful in combination with touchscreen. Here's one clip illustrating the concept:
http://www.youtube.com/user/instantdecomposer#p/a/u/2/Qo1CwYxmplE
The toxy lib is discontinued in Pd-extended 0.43. Tried to find an alternative, asked on the Pd forum. No solution so far. I explored gem for GUI purposes, but this introduces even more dependencies. Data-structures seem an option at first sight, but can not provide large reactive area's (only the center pixel of an object is reactive). Good old [MouseState] doesn't know where the window is. In a brief moment of optimism, I even considered taking up maintaince of toxy, but the code is total hocus pocus to me.
In the meantime, one of those live-perfo tools, Slice//Jockey, has started to spread around the world and is being used by some performers and composers. As you may understand, I am particularly concerned to provide a 0.43-compatible version as soon as possible. Any help to find a window-related mouse-capturing method, working in 0.42 and 0.43 alike, is very much appreciated.
Slice//Jockey is pretty awesome, by the way, I just watched the video. I think iemguts/receivecanvas will do what you need.
.hc
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
----- Original Message -----
From: katja katjavetter@gmail.com To: pd-list@iem.at Cc: Sent: Wednesday, November 2, 2011 10:24 AM Subject: [PD] how to capture window-related mouse-events when toxy is discontinued?
Hello,
It happens to be the case that mouse-event capturing as done by [toxy/tot] is crucial to my Pd performance setups. The object gives xy positions relative to a window, not to the screen(s). These coordinates are used to move GUI's around on a large xy-field, like a multiple-control Kaoss Pad. Specially useful in combination with touchscreen. Here's one clip illustrating the concept:
http://www.youtube.com/user/instantdecomposer#p/a/u/2/Qo1CwYxmplE
The toxy lib is discontinued in Pd-extended 0.43. Tried to find an alternative, asked on the Pd forum. No solution so far. I explored gem for GUI purposes, but this introduces even more dependencies. Data-structures seem an option at first sight, but can not provide large reactive area's (only the center pixel of an object is reactive).
Are you in edit mode in that video? If so, data structures will react accordingly.
In run mode there is a way to make the entire polygon reactive (instead of just a little 5x5 pixel "hot spot"), but it's hacky.
-Jonathan
Good old [MouseState] doesn't know where the window is. In a brief moment of optimism, I even considered taking up maintaince of toxy, but the code is total hocus pocus to me.
In the meantime, one of those live-perfo tools, Slice//Jockey, has started to spread around the world and is being used by some performers and composers. As you may understand, I am particularly concerned to provide a 0.43-compatible version as soon as possible. Any help to find a window-related mouse-capturing method, working in 0.42 and 0.43 alike, is very much appreciated.
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The toxy lib is discontinued in Pd-extended 0.43. Tried to find an alternative, asked on the Pd forum. No solution so far. I explored gem for GUI purposes, but this introduces even more dependencies. Data-structures seem an option at first sight, but can not provide large reactive area's (only the center pixel of an object is reactive).
Are you in edit mode in that video? If so, data structures will react
accordingly.In run mode there is a way to make the entire polygon reactive (instead
of just a little 5x5 pixel "hot spot"), but it's hacky.
It can happen that data structures (tcl/tk) can be a bit heavy to
manipulate, and will cause dropouts.
If it's in edit mode, the "whole polygon" will create trouble when
clicking it to position an object, no? unless that's not a data structure,
but a canvas with a small selection square.
----- Original Message -----
From: João Pais jmmmpais@googlemail.com To: katja katjavetter@gmail.com; "pd-list@iem.at" pd-list@iem.at; Jonathan Wilkes jancsika@yahoo.com Cc: Sent: Wednesday, November 2, 2011 12:44 PM Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
The toxy lib is discontinued in Pd-extended 0.43. Tried to find an alternative, asked on the Pd forum. No solution so far. I explored gem for GUI purposes, but this introduces even more dependencies. Data-structures seem an option at first sight, but can not provide large reactive area's (only the center pixel of an object is reactive).
Are you in edit mode in that video? If so, data structures will react
accordingly.
In run mode there is a way to make the entire polygon reactive (instead of
just a
little 5x5 pixel "hot spot"), but it's hacky.
It can happen that data structures (tcl/tk) can be a bit heavy to manipulate, and will cause dropouts.
If it's in edit mode, the "whole polygon" will create trouble when clicking it to position an object, no?
Well, instead of "whole polygon" I should say "all the visualizations associated with a scalar". In edit mode you'll get a bounding box around the scalar and you can drag it just as any pd object. The [struct] outlet will notify you with a "displace" msg when you do this, and you can use the pointer element from that message to get the current x and y for that scalar.
-Jonathan
unless that's not a data structure, but a canvas with a small selection square.
Well, instead of "whole polygon" I should say "all the visualizations
associated with a scalar". In edit mode you'll get a bounding box around the scalar and
you can drag it just as any pd object. The [struct] outlet will notify you with a
"displace" msg when you do this, and you can use the pointer element from that message to get
the current x and y for that scalar.
I thought that with "whole polygon" you meant the big canvas in the
background. that's the problem I was pointing at, how to make it possible
so that a click in the background (without the mouse detector) can make a
scalar move instantly there.
Wow, so many answers in so short time. Thank you all.
To clarify, the moving squares in the video are sliders and / or radiobuttons, and they are moved in runtime. Attached is a patch demonstrating the idea, using [toxy/tot].
As it seems, [iemguts/receivecanvas] could do this job indeed. It captures cursor position relative to the object's containing window, or relative to a parent if so desired. Phew, this will save my projects! I never knew about the existence of [iemguts/receivecanvas]. It has no helpfile. I'd be happy to make one though. Hopefully the iem libs will stay a bit longer than toxy, though they're now categorized as 'unsupported, included libraries'.
Jonathan, can you explain how a larger area of a polygon can be made reactive in runtime? Do you have a demo patch? I'm still interested in the data structure route, since I use them for parameter values anyway, and it is a bit underestimated aspect of Pure Data in my view.
Katja
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-02 18:45, katja wrote:
Wow, so many answers in so short time. Thank you all.
To clarify, the moving squares in the video are sliders and / or radiobuttons, and they are moved in runtime. Attached is a patch demonstrating the idea, using [toxy/tot].
As it seems, [iemguts/receivecanvas] could do this job indeed. It captures cursor position relative to the object's containing window, or relative to a parent if so desired. Phew, this will save my projects! I never knew about the existence of [iemguts/receivecanvas]. It has no helpfile. I'd be happy to make one though. Hopefully the iem libs will stay a bit longer than toxy, though they're now categorized as 'unsupported, included libraries'.
it has; at least in the svn [1], there is a "help/" holder with a helpfile.
fgmasdr IOhannes
[1] https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/iem/...
On Wed, Nov 2, 2011 at 6:54 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
I never knew about the existence of [iemguts/receivecanvas]. It has no helpfile. I'd be happy to make one though. Hopefully the iem libs will stay a bit longer than toxy, though they're now categorized as 'unsupported, included libraries'.
it has; at least in the svn [1], there is a "help/" holder with a helpfile.
Ah yes. File receivecanvas-help.pd is not in my Pd-extended 0.42.5 install, but it is present in 0.43 nightly builds, like other iemguts help files missing in this 0.42.5 binary. Thanks for pointing to [receivecanvas], and even more thanks for providing these useful classes.
Katja
On Nov 2, 2011, at 4:15 PM, katja wrote:
On Wed, Nov 2, 2011 at 6:54 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
I never knew about the existence of [iemguts/receivecanvas]. It has no helpfile. I'd be happy to make one though. Hopefully the iem libs will stay a bit longer than toxy, though they're now categorized as 'unsupported, included libraries'.
it has; at least in the svn [1], there is a "help/" holder with a helpfile.
Ah yes. File receivecanvas-help.pd is not in my Pd-extended 0.42.5 install, but it is present in 0.43 nightly builds, like other iemguts help files missing in this 0.42.5 binary. Thanks for pointing to [receivecanvas], and even more thanks for providing these useful classes.
As for iemguts support, I think IOhannes is actively developing iemguts, so its supported on that level. It just needs someone to make sure that it continues to work properly in Pd-extended. That should be a pretty easy job, since iemguts is based somewhat off of the Library Template.
.hc
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne
Update: replaced [toxy/tot] with [iemguts/receivecanvas] in various patches, it is indeed the perfect alternative for capturing mouse-events. Even messages 'motion', 'mouse' and 'mouseup' are identical.
Hans, it could also be used in [hcs/mouse_region], which currently does not work in 0.43.
Katja.
----- Original Message -----
From: katja katjavetter@gmail.com To: pd-list@iem.at Cc: Sent: Wednesday, November 2, 2011 1:45 PM Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
Wow, so many answers in so short time. Thank you all.
To clarify, the moving squares in the video are sliders and / or radiobuttons, and they are moved in runtime. Attached is a patch demonstrating the idea, using [toxy/tot].
As it seems, [iemguts/receivecanvas] could do this job indeed. It captures cursor position relative to the object's containing window, or relative to a parent if so desired. Phew, this will save my projects! I never knew about the existence of [iemguts/receivecanvas]. It has no helpfile. I'd be happy to make one though. Hopefully the iem libs will stay a bit longer than toxy, though they're now categorized as 'unsupported, included libraries'.
Jonathan, can you explain how a larger area of a polygon can be made reactive in runtime? Do you have a demo patch?
Sure. The attached allows the 50x30 polygon to be click-dragged anywhere within the polygon-- basically ds hotspots happen in a 10x10 quadrant within the polygon when an x/y pair is specified with a field variable, so I'm forcing hotspots for the entire polygon by spacing all field value coordinates no more than 10 pixels from each other. (You can overlay a simpler polygon if you want a cleaner-looking control surface.)
My example allows click-dragging, but leaves out the ability to click-select an object and move it by clicking a blank spot on the canvas. You could do this by defining an additional data structure with a white rectangle, and make a matrix of scalars to fill the canvas. Then when you click a "blank" area of the canvas, you're actually clicking the white scalar rectangle which will send a "click" message to its [struct], and you can then move the selected control-surface scalar to the corresponding quadrant. (That's the hacky part.)
-Jonathan
I'm still interested in the data structure route, since I use them for parameter values anyway, and it is a bit underestimated aspect of Pure Data in my view.
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, Nov 2, 2011 at 11:08 PM, Jonathan Wilkes jancsika@yahoo.com
The attached allows the 50x30 polygon to be click-dragged anywhere within the polygon-- basically ds hotspots happen in a 10x10 quadrant within the polygon when an x/y pair is specified with a field variable, so I'm forcing hotspots for the entire polygon by spacing all field value coordinates no more than 10 pixels from each other. (You can overlay a simpler polygon if you want a cleaner-looking control surface.)
That's a lovely demo Jonathan. The small squares have their own esthetic. This approach is less hacky than my moving radiobuttons. Do you use it in practice, as GUI elements? It is very heavy on cpu.
Katja
----- Original Message -----
From: katja katjavetter@gmail.com To: pd-list@iem.at Cc: Sent: Wednesday, November 2, 2011 7:58 PM Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
On Wed, Nov 2, 2011 at 11:08 PM, Jonathan Wilkes jancsika@yahoo.com
The attached allows the 50x30 polygon to be click-dragged anywhere within the polygon-- basically ds hotspots happen in a 10x10 quadrant
within
the polygon when an x/y pair is specified with a field variable, so I'm
forcing
hotspots for the entire polygon by spacing all field value coordinates no
more
than 10 pixels from each other. (You can overlay a simpler polygon if you
want
a cleaner-looking control surface.)
That's a lovely demo Jonathan. The small squares have their own esthetic. This approach is less hacky than my moving radiobuttons. Do you use it in practice, as GUI elements? It is very heavy on cpu.
I've used scalars with a single rectangle as the visual element-- however, just mousing around it looks like numberbox, vradio, my scalars from the demo, and a simple filled rectangle can all cause large cpu jumps when displacing or moving.
How does the cpu usage in my demo compare to your patch where you use a radiobutton?
In practice, I've actually used arrays of scalars for a little video game, but the sound was secondary.
-Jonathan
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, Nov 3, 2011 at 1:30 AM, Jonathan Wilkes jancsika@yahoo.com 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%
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
----- 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 jancsika@yahoo.com 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 points 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
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
have 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 jancsika@yahoo.com 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 points 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
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 parse, 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 have 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 jancsika@yahoo.com 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 points 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
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 parse, 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 have 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 points 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
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 parse, 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 have 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 points 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
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
----- 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 jancsika@yahoo.com 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%
The old joke: If the black box can survive a crash, why don't they just build the whole airplane out of the black box?
Similarly: If a 2D geo in a gem window is the most efficient way to draw an object, why not just make canvases be opengl windows?
I imagine the answer might be "because it's not that simple", but I thought I'd ask anyway.
-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
On Nov 9, 2011, at 12:33 PM, Jonathan Wilkes wrote:
----- 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 jancsika@yahoo.com 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%
The old joke: If the black box can survive a crash, why don't they just build the whole airplane out of the black box?
Similarly: If a 2D geo in a gem window is the most efficient way to draw an object, why not just make canvases be opengl windows?
I imagine the answer might be "because it's not that simple", but I thought I'd ask anyway.
That's what TkZinc is: a Tk canvas written to use OpenGL. http://www.tkzinc.org
.hc
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
Le 2011-11-09 à 12:39:00, Hans-Christoph Steiner a écrit :
That's what TkZinc is: a Tk canvas written to use OpenGL. http://www.tkzinc.org
In 2007, Chun wanted to look into TkZinc. I came up with the idea of a compatibility layout class, so that TkZinc could become a drop-in replacement for TkCanvas (because it isn't fully compatible). In the end, we gave up. It's possible that it would work better now.
But I think that modifying part of TkCanvas's source to improve its speed (while still using X11) is another possible avenue...
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Nov 9, 2011, at 12:54 PM, Mathieu Bouchard wrote:
Le 2011-11-09 à 12:39:00, Hans-Christoph Steiner a écrit :
That's what TkZinc is: a Tk canvas written to use OpenGL. http://www.tkzinc.org
In 2007, Chun wanted to look into TkZinc. I came up with the idea of a compatibility layout class, so that TkZinc could become a drop-in replacement for TkCanvas (because it isn't fully compatible). In the end, we gave up. It's possible that it would work better now.
But I think that modifying part of TkCanvas's source to improve its speed (while still using X11) is another possible avenue...
ANother idea is to make a [tkzinc] object that allows people to make all sorts of GUI objects in Pd that are built on top of TkZinc's OpenGL.
.hc
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
Le 2011-11-09 à 14:01:00, Hans-Christoph Steiner a écrit :
ANother idea is to make a [tkzinc] object that allows people to make all sorts of GUI objects in Pd that are built on top of TkZinc's OpenGL.
You mean that each [tkzinc] object would be a TkCanvas-like widget embedded inside of the TkCanvas that would still be used ?
It wouldn't solve the problem that people are talking about.
But perhaps you mean something else.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Nov 9, 2011, at 2:44 PM, Mathieu Bouchard wrote:
Le 2011-11-09 à 14:01:00, Hans-Christoph Steiner a écrit :
ANother idea is to make a [tkzinc] object that allows people to make all sorts of GUI objects in Pd that are built on top of TkZinc's OpenGL.
You mean that each [tkzinc] object would be a TkCanvas-like widget embedded inside of the TkCanvas that would still be used ?
It wouldn't solve the problem that people are talking about.
But perhaps you mean something else.
You can't put a tkzinc canvas into a window on a canvas? That's what I mean.
.hc
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. -Admiral Gene LeRocque
Le 2011-11-09 à 20:53:00, Hans-Christoph Steiner a écrit :
On Nov 9, 2011, at 2:44 PM, Mathieu Bouchard wrote:
You mean that each [tkzinc] object would be a TkCanvas-like widget embedded inside of the TkCanvas that would still be used ? It wouldn't solve the problem that people are talking about. But perhaps you mean something else.
You can't put a tkzinc canvas into a window on a canvas? That's what I mean.
Oh, ok then.
I didn't think that you were suggesting that.
This can work (but has the same caveats as embedding any Tk Widget instead of Tk Item. Think of how [popup] and [button] and such handle clicking and focus)
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-09 à 09:33:00, Jonathan Wilkes a écrit :
Similarly: If a 2D geo in a gem window is the most efficient way to draw an object, why not just make canvases be opengl windows?
Are we comparing percentages with an equivalent 2-D GEO ? E.g. a radiobutton that has n=8 needs between 9 and 12 canvas items. This has to translate to between 9 and 12 GEM Geos. How many geos were used in the GEM test ?
I'd believe it if GEM is fastest anyway, but the numbers shouldn't be made to be more dramatic than they deserve, so, that's why I'm asking.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: katja katjavetter@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Wednesday, November 9, 2011 1:00 PM Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
Le 2011-11-09 à 09:33:00, Jonathan Wilkes a écrit :
Similarly: If a 2D geo in a gem window is the most efficient way to draw an
object, why not just make canvases be opengl windows?
Are we comparing percentages with an equivalent 2-D GEO ? E.g. a radiobutton that has n=8 needs between 9 and 12 canvas items.
In katja's demo the radiobutton had n=1, so I guess it's just two rectangles.
This has to translate to between 9 and 12 GEM Geos. How many geos were used in the GEM test ?
I'd believe it if GEM is fastest anyway, but the numbers shouldn't be made to be more dramatic than they deserve, so, that's why I'm asking.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-09 à 11:10:00, Jonathan Wilkes a écrit :
In katja's demo the radiobutton had n=1, so I guess it's just two rectangles.
How useful and typical is a radiobutton with n=1 ?
The demo ought to have something realistic to it.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: katja katjavetter@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Wednesday, November 9, 2011 2:45 PM Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
Le 2011-11-09 à 11:10:00, Jonathan Wilkes a écrit :
In katja's demo the radiobutton had n=1, so I guess it's just two
rectangles.
How useful and typical is a radiobutton with n=1 ?
Getting user input by dragging a rectangle is very useful and typical. (See [cnv] help.)
The demo ought to have something realistic to it.
I can think of some things a clear demo would have:
base level gui interaction (moving a single rectangle) changing text by scrolling (scrolling in a numberbox) multi-slider (drawing in an array) complex polygon (tkzinc svg tiger or something like it)
A tcl/tkzinc comparison would be nice, but I'd also like to see the results with a toolkit like Qt. (Unfortunately I had trouble last time I tried to get the Qt dev stuff running on my laptop.)
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-09 à 12:40:00, Jonathan Wilkes a écrit :
How useful and typical is a radiobutton with n=1 ?
Getting user input by dragging a rectangle is very useful and typical. (See [cnv] help.)
But does that work outside of [cnv], and does that work with radiobuttons ?
Anyway, I think that it's better to concentrate on testing large sets of GUI elements because it is with those large sets that responsiveness problems do occur, and the CPU percentages are rarely obvious (not so proportional). The large sets ought to be as realistic as possible, though, not insane stress tests. But it's hard to be representative with Pd, because everybody is using Pd in a different way.
Perhaps the MTL libraries (by Thomas O. Fredericks) could be good tests, because they contain a fair amount of sophisticated and useful GOP abstractions meant to be used by Pd users of all levels. But I have rarely used them personally.
A tcl/tkzinc comparison would be nice, but I'd also like to see the results with a toolkit like Qt. (Unfortunately I had trouble last time I tried to get the Qt dev stuff running on my laptop.)
What was wrong with the Qt dev stuff ? I think that it might be enlightening to know that.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: katja katjavetter@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Wednesday, November 9, 2011 5:30 PM Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
Le 2011-11-09 à 12:40:00, Jonathan Wilkes a écrit :
How useful and typical is a radiobutton with n=1 ?
Getting user input by dragging a rectangle is very useful and typical.
(See [cnv] help.)
But does that work outside of [cnv], and does that work with radiobuttons ?
If by "that" you mean dragging in edit mode, then no. If by "that" you mean "getting user input by dragging a rectangle" then see also [grid], [vsl], [hsl] and probably lots of others that I'm forgetting.
I think katja was using [tot] to get radiobutton to act as a draggable ui rectangle.
Anyway, I think that it's better to concentrate on testing large sets of GUI elements because it is with those large sets that responsiveness problems do occur, and the CPU percentages are rarely obvious (not so proportional). The large sets ought to be as realistic as possible, though, not insane stress tests. But it's hard to be representative with Pd, because everybody is using Pd in a different way.
Perhaps the MTL libraries (by Thomas O. Fredericks) could be good tests, because they contain a fair amount of sophisticated and useful GOP abstractions meant to be used by Pd users of all levels. But I have rarely used them personally.
A tcl/tkzinc comparison would be nice, but I'd also like to see the
results with a toolkit like Qt. (Unfortunately I had trouble last time I tried to get the Qt dev stuff running on my laptop.)
What was wrong with the Qt dev stuff ? I think that it might be enlightening to know that.
I didn't mean to imply there was anything wrong with it. It had to do with accidentally enabling a testing repo on my OS and ending up with some Qt libs from one version and some from another. From what I've seen so far Qt's documentation is excellent, as are the development tools.
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-09 à 15:39:00, Jonathan Wilkes a écrit :
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca
(why does it always look like you click «Forward» to do a reply ?)
But does that work outside of [cnv], and does that work with radiobuttons ?
If by "that" you mean dragging in edit mode, then no.
Oh ok.
I think katja was using [tot] to get radiobutton to act as a draggable ui rectangle.
Ah, somehow I had forgotten that and thought that we were in a more general discussion about Tk vs GEM/GL.
What was wrong with the Qt dev stuff ? I think that it might be enlightening to know that.
I didn't mean to imply there was anything wrong with it.
Sorry, I meant : « what problems did you encounter with it ? »
It had to do with accidentally enabling a testing repo on my OS and ending up with some Qt libs from one version and some from another.
Oh yeah. Sounds like fun ! ;)
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Wed, Nov 9, 2011 at 7:00 PM, Mathieu Bouchard matju@artengine.ca wrote:
Are we comparing percentages with an equivalent 2-D GEO ? E.g. a radiobutton that has n=8 needs between 9 and 12 canvas items. This has to translate to between 9 and 12 GEM Geos. How many geos were used in the GEM test ?
I'd believe it if GEM is fastest anyway, but the numbers shouldn't be made to be more dramatic than they deserve, so, that's why I'm asking.
How many geos doesn't seem to matter much. A 'Gem gui object' could for example be a draggable geo with a texture, or a set of 5 geo's moving together when dragged. The cpu load caused by dragging is the same in both cases. The percentages in my small test were rough indications as seen in top, for Pd and Pd-extended processes. In OSX's Activity Monitor, the process WindowServer (not shown in top), does a few % as well for any mouse activity, that's what I saw only later.
I've done a rather intensive attempt to do all gui's in Gem some time ago. It was promising, but there were a couple disadvantages as well. It's documented on the Pd forum:
http://puredata.hurleur.com/sujet-5515-gem-alternative-guis
A demo patch 'WaveRefinery.pd' is there (login, post #5), with animated pictogram buttons, toggles and xy-controls in a Gem window. It gives a nice impression of possibilities.
Katja
Le 2011-11-09 à 21:57:00, katja a écrit :
How many geos doesn't seem to matter much. A 'Gem gui object' could for example be a draggable geo with a texture, or a set of 5 geo's moving together when dragged. The cpu load caused by dragging is the same in both cases.
It's like that whenever the textures are already uploaded (and are not being reuploaded) and that there's a GPU that does nearly all of the work. In that case, all the CPU has to do is run the Pd/GEM objects, and when pix objects are idle, all that GEM does it tell the GPU what to do, so it's really fast, even when it's repetitive.
But with certain «light» kinds of GPU, the work is split between the CPU and GPU (I don't know whether there are still new devices like that, but my 2005 laptop was like that and I only got a new one this year).
A demo patch 'WaveRefinery.pd' is there (login, post #5), with animated pictogram buttons, toggles and xy-controls in a Gem window. It gives a nice impression of possibilities.
When you try dragging a circle or square from its edge, it does not work (the click detection does not work, seems to be using a different radius). If you click inside, then the shape jumps so as to become centered, which is not what I'd expect.
But it does seem like a quite good patch.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: katja katjavetter@gmail.com To: pd-list@iem.at Cc: Sent: Wednesday, November 2, 2011 7:58 PM Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
On Wed, Nov 2, 2011 at 11:08 PM, Jonathan Wilkes jancsika@yahoo.com
The attached allows the 50x30 polygon to be click-dragged anywhere within the polygon-- basically ds hotspots happen in a 10x10 quadrant
within
the polygon when an x/y pair is specified with a field variable, so I'm
forcing
hotspots for the entire polygon by spacing all field value coordinates no
more
than 10 pixels from each other. (You can overlay a simpler polygon if you
want
a cleaner-looking control surface.)
That's a lovely demo Jonathan. The small squares have their own esthetic. This approach is less hacky than my moving radiobuttons. Do you use it in practice, as GUI elements? It is very heavy on cpu.
Oh, wow-- lines, polygons, and text of scalars get deleted and recreated every time they get moved. This is what gets sent to the GUI for every motion event when dragging a scalar (in run mode here):
.x291cf70.c delete curve291f238
.x291cf70.c delete curve291f238
.x291cf70.c create polygon
217 175
227 175
227 185
217 185
-width 1.000000
-fill #ff0000 -outline #000000
-tags curve291f238
.x291cf70.c create line
172 130
272 130
272 230
172 230
172 130
-width 1.000000
-fill #000000
-tags curve291f238
I imagine if this were changed to tag the entire scalar and move it by tag, it would improve the performance quite a bit.
-Jonathan
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, Nov 4, 2011 at 3:46 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Oh, wow-- lines, polygons, and text of scalars get deleted and recreated every time they get moved. This is what gets sent to the GUI for every motion event when dragging a scalar (in run mode here):
.x291cf70.c delete curve291f238 .x291cf70.c delete curve291f238 .x291cf70.c create polygon
217 175
227 175
227 185
217 185
-width 1.000000
-fill #ff0000 -outline #000000
-tags curve291f238 .x291cf70.c create line
172 130
272 130
272 230
172 230
172 130
-width 1.000000
-fill #000000
-tags curve291f238I imagine if this were changed to tag the entire scalar and move it by tag, it would improve the performance quite a bit.
Possibly the idea behind the polygons was more to manipulate (or visually represent) the character of sound by altering a polygon's shape. See help browser >> 4.data.structures/07.sequencer.pd. Then it is obvious that a polygon must be redrawn everytime. In my view, changing shapes is much more imaginative than dragging fixed shapes around. But in live performance, it is easier to hit a 50*50 pix square on a touch screen and drag it around, than trying to pick a polygon's minuscule corner with a mouse.
Katja
----- Original Message -----
From: katja katjavetter@gmail.com To: pd-list@iem.at Cc: Sent: Friday, November 4, 2011 5:23 AM Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
On Fri, Nov 4, 2011 at 3:46 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Oh, wow-- lines, polygons, and text of scalars get deleted and recreated
every time they
get moved. This is what gets sent to the GUI for every motion event when
dragging a
scalar (in run mode here):
.x291cf70.c delete curve291f238 .x291cf70.c delete curve291f238 .x291cf70.c create polygon
217 175
227 175
227 185
217 185
-width 1.000000
-fill #ff0000 -outline #000000
-tags curve291f238 .x291cf70.c create line
172 130
272 130
272 230
172 230
172 130
-width 1.000000
-fill #000000
-tags curve291f238I imagine if this were changed to tag the entire scalar and move it by tag, it would improve the performance quite a bit.
Possibly the idea behind the polygons was more to manipulate (or visually represent) the character of sound by altering a polygon's shape.
Functionally there is no difference between altering a polygon's shape and the way I am moving it.
See help browser >> 4.data.structures/07.sequencer.pd. Then it is obvious that a polygon must be redrawn everytime.
It doesn't have to get deleted and recreated each time, does it? Wouldn't a single canvas coords subcommand be more efficient?
In my view, changing shapes is much more imaginative than dragging fixed shapes around. But in live performance, it is easier to hit a 50*50 pix square on a touch screen and drag it around, than trying to pick a polygon's minuscule corner with a mouse.
If you're just moving shapes, you might consider doing everything in edit mode with [cnv] objects-- it will be more efficient than data structures (which still get deleted when moving them in edit mode-- don't understand that at all) and you can track their position with the "get_pos" message.
-Jonathan
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2011-11-04 à 07:37:00, Jonathan Wilkes a écrit :
Functionally there is no difference between altering a polygon's shape and the way I am moving it.
In Tk, to change the coordinates of a canvas-item, you don't have to delete it and recreate it. There's always a canvas-method named « coords » that takes the same number of position arguments that the item-constructor did. So for a rectangle-item, you give two points (four numbers) and for a N-gon (N-sided polygon), you give N points (2*N points).
It might not be much faster, though. I expect it to be only a tiny bit faster. Just a bit less time parsing, about one less malloc and one less free (perhaps several, because you have to remove a tag and add back the exact same). It doesn't actually redraw anything between the delete and the create.
Now that I think of it, the bbox computation (necessary for scheduling the redraw) is done twice using create/delete, only once using coords, but that should be a small amount of time compared to parsing the command.
BTW, extremely long strings of commands might be parsed repeatedly by the client side in pd 43, because it's using [info complete] (just like desiredata). But in practice, I didn't see it be a problem in profiling desiredata's client's cpu usage, and I think pd 43 does it just the same. I didn't profile in all situations, though, so, the technique might hit problems with big arrays, big DS, big moves or abuse of [print] or of other post()/error().
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: katja katjavetter@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Friday, November 4, 2011 1:18 PM Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
Le 2011-11-04 à 07:37:00, Jonathan Wilkes a écrit :
Functionally there is no difference between altering a polygon's shape
and the way I am moving it.
In Tk, to change the coordinates of a canvas-item, you don't have to delete it and recreate it. There's always a canvas-method named « coords » that takes the same number of position arguments that the item-constructor did. So for a rectangle-item, you give two points (four numbers) and for a N-gon (N-sided polygon), you give N points (2*N points).
It might not be much faster, though. I expect it to be only a tiny bit faster. Just a bit less time parsing, about one less malloc and one less free (perhaps several, because you have to remove a tag and add back the exact same). It doesn't actually redraw anything between the delete and the create.
It seems like it does redraw stuff between the delete and create for a scalar with enough canvas items associated with it. For example, if you make a ds array where each element is a little 10x10 rectangle and plot it with an array size greater than 100, you start to get a kind of strobing effect over the entire array when moving one element with the mouse.
Now that I think of it, the bbox computation (necessary for scheduling the redraw) is done twice using create/delete, only once using coords, but that should be a small amount of time compared to parsing the command.
BTW, extremely long strings of commands might be parsed repeatedly by the client side in pd 43, because it's using [info complete] (just like desiredata). But in practice, I didn't see it be a problem in profiling desiredata's client's cpu usage, and I think pd 43 does it just the same. I didn't profile in all situations, though, so, the technique might hit problems with big arrays, big DS, big moves or abuse of [print] or of other post()/error().
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-04 à 10:37:00, Jonathan Wilkes a écrit :
It seems like it does redraw stuff between the delete and create for a scalar with enough canvas items associated with it. For example, if you make a ds array where each element is a little 10x10 rectangle and plot it with an array size greater than 100, you start to get a kind of strobing effect over the entire array when moving one element with the mouse.
Ok, whenever you do see it blink, then it's probably quite less efficient than with «coords».
(though sometimes, some benchmarks give surprising results. but it's hard to benchmark it completely... I had to modify Tk to get it to print the time it takes to redraw, because that part of Tk isn't overridable from Tcl nor from a C plugin for Tcl).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Ivica Ico Bukvic -
Jonathan Wilkes -
João Pais -
katja -
Mathieu Bouchard