The new release includes following fixes:
*tooltips (partially based on Jonathan Wilkes's implementation) that appear in form of speech bubbles next to the object they relate to. Reliable detection of objects. Also works with gop objects. *major overhaul of the font resizing dialog/logic--font resizing made simple (everything scales proportionately except for gui objects whose properties obey user-set settings) *font-based zoom using ctrl+mousewheel *font resizing integrated in the infinite undo *hslider/vslider instead of possibly corrupting data due to its values tied to the drawing logic output unaltered data where possible (e.g. float values that fall within the range of the slider) *minor cosmetic improvements to hslider/vslider *several minor bug-fixes *hslider and vslider redraw their slider properly when resized *Minor build/documentation improvements *Removed selection as part of the undo queue as it vastly limits ability to use infinite undo's potential
L2Ork supports builds for both 32-bit and 64-bit Linux systems and can be downloaded from the usual place:
http://l2ork.music.vt.edu/main/?page_id=56
On a related note, disis_wiimote has been bumped to version 0.8.0. It now supports automatic detection of all extensions including motionplus. New l2ork version of libcwiid required (also available on the same page). Coming up in the next release (hopefully!) soon, support for pass-through mode (e.g. motionplus + nunchuk).
As usual, bug reports are in high demand, so get busy and let me know of any potential hiccups.
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
Sounds great. I'll try it out in a bit.
Just curious-- if I send [tip 1 Hello Canvas( to a canvas, where on the canvas does the tooltip appear?
-Jonathan
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: pd-list@iem.at; linux-audio-user@lists.linuxaudio.org; piksel@piksel.no Cc: Sent: Monday, March 5, 2012 12:07 PM Subject: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
T he new release includes following fixes:
*tooltips (partially based on Jonathan Wilkes's implementation) that appear in form of speech bubbles next to the object they relate to. Reliable detection of objects. Also works with gop objects. *major overhaul of the font resizing dialog/logic--font resizing made simple (everything scales proportionately except for gui objects whose properties obey user-set settings) *font-based zoom using ctrl+mousewheel *font resizing integrated in the infinite undo *hslider/vslider instead of possibly corrupting data due to its values tied to the drawing logic output unaltered data where possible (e.g. float values that fall within the range of the slider) *minor cosmetic improvements to hslider/vslider *several minor bug-fixes *hslider and vslider redraw their slider properly when resized *Minor build/documentation improvements *Removed selection as part of the undo queue as it vastly limits ability to use infinite undo's potential
L2Ork supports builds for both 32-bit and 64-bit Linux systems and can be downloaded from the usual place:
http://l2ork.music.vt.edu/main/?page_id=56
On a related note, disis_wiimote has been bumped to version 0.8.0. It now supports automatic detection of all extensions including motionplus. New l2ork version of libcwiid required (also available on the same page). Coming up in the next release (hopefully!) soon, support for pass-through mode (e.g. motionplus + nunchuk).
As usual, bug reports are in high demand, so get busy and let me know of any potential hiccups.
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Sounds great. I'll try it out in a bit.
Just curious-- if I send [tip 1 Hello Canvas( to a canvas, where on the canvas does the tooltip appear?
-Jonathan
Next to the cursor. We can alter that if this proves to be unintuitive.
Best wishes,
Ico
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: 'Jonathan Wilkes' jancsika@yahoo.com; 'p1k53l workshop' piksel@piksel.no; pd-list@iem.at; linux-audio-user@lists.linuxaudio.org Cc: Sent: Monday, March 5, 2012 2:09 PM Subject: RE: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
Sounds great. I'll try it out in a bit.
Just curious-- if I send [tip 1 Hello Canvas( to a canvas, where on the canvas does the tooltip appear?
-Jonathan
Next to the cursor. We can alter that if this proves to be unintuitive.
Well, I personally prefer the "status bar" approach than tooltips that nestle up next to my mouse-- that's why I always printed out the tooltip at the bottom of the patch (or at the top if the user is mousing at the bottom). This is basically the Firefox approach seen when you mouse over a link on a web page and a little label appears at the bottom right of the patch (or bottom left, depending on where your mouse is).
However, I think I combined two related features that may not belong together:
- tooltips
- canvas tips
Even though it's not my preference, your tooltip placement seems to work well and is probably the clearest placement for the new user (who will probably benefit most from using them).
Btw-- one thing I notice is that a) I can generate a tip for the object itself while the inlet appears highlighted, and b) once I generate an inlet tip, if I move the mouse horizontally to the right the inlet will continue to be highlighted even though the mouse is no longer over it.
However, I think canvas tips should still be placed at the bottom of the canvas, similar to Firefox url links at the bottom of the page. Two important use cases off the top of my head:
- tutorial where the text gets displayed in reaction to user input. For example, the
tip can tell the user how to spin a number box, and after the user spins it the tip can change to let the user know they did it correctly, and move on to the next part of the tutorial. In general this can make tutorial text a lot more interactive. 2) a revised pddplink could use it to display the actual link location when link text is displayed.
-Jonathan
Best wishes,
Ico
Well, I personally prefer the "status bar" approach than tooltips that nestle up next to my mouse-- that's why I always printed out the tooltip at the bottom of the patch (or at the top if the user is mousing at the bottom). This is basically the Firefox approach seen when you mouse over a link on a web page and a little label appears at the bottom right of the patch (or bottom left, depending on where your mouse is).
However, I think I combined two related features that may not belong together:
- tooltips
- canvas tips
Even though it's not my preference, your tooltip placement seems to work well and is probably the clearest placement for the new user (who will probably benefit most from using them).
No problem, I can make the canvas tips appear at the bottom whereas all others will appear in place. This has been already fixed in the newest version I am currently building (20120305).
Btw-- one thing I notice is that a) I can generate a tip for the object itself while the inlet appears highlighted, and b) once I generate an inlet tip, if I move the mouse horizontally to the right the inlet will continue to be highlighted even though the mouse is no longer over it.
The nlet highlighting is "magnetic" by default to allow for easier patching. I can however see how this could be distracting in terms of object tip "trumping" the nlet tip. Part of this I suspect is toolkit's limitations because tcl/tk's "current" tag inside canvas is rather crude and not necessarily very useful within the context of Pd patching (e.g. when you click on an outlet, "current" tag is stuck to whatever you've clicked even if you are dragging a mouse to another nlet, which means there is no way to highlight nlets when patching).
20120305 version that is currently building now does all the binding logic inside c code and things run a lot smoother.
Cheers!
A few minor bugs crept into the new tooltip implementation, so 20120306 version is now out. Tooltips now support both dockable behavior for the manual tooltips and cursor-centric text bubbles for dynamic tooltips. Also, all the shortcomings of tcl/tk's Enter/Leave events has been circumvented by using C implementation of tooltips. Other improvements include scalable fonts, removal of redundant tooltips, and correct offset calculation for objects.
http://l2ork.music.vt.edu/main/?page_id=56
Pd-l2ork can be also found on git at https://github.com/pd-l2ork
Cheers!
Best wishes,
Ico
On Mon, Mar 5, 2012 at 18:07, Ivica Ico Bukvic ico@vt.edu wrote:
The new release includes following fixes:
*tooltips (partially based on Jonathan Wilkes's implementation) that appear in form of speech bubbles next to the object they relate to. Reliable detection of objects. Also works with gop objects. *major overhaul of the font resizing dialog/logic--font resizing made simple (everything scales proportionately except for gui objects whose properties obey user-set settings) *font-based zoom using ctrl+mousewheel *font resizing integrated in the infinite undo *hslider/vslider instead of possibly corrupting data due to its values tied to the drawing logic output unaltered data where possible (e.g. float values that fall within the range of the slider) *minor cosmetic improvements to hslider/vslider *several minor bug-fixes *hslider and vslider redraw their slider properly when resized *Minor build/documentation improvements *Removed selection as part of the undo queue as it vastly limits ability to use infinite undo's potential
L2Ork supports builds for both 32-bit and 64-bit Linux systems and can be downloaded from the usual place:
http://l2ork.music.vt.edu/main/?page_id=56
On a related note, disis_wiimote has been bumped to version 0.8.0. It now supports automatic detection of all extensions including motionplus. New l2ork version of libcwiid required (also available on the same page). Coming up in the next release (hopefully!) soon, support for pass-through mode (e.g. motionplus + nunchuk).
As usual, bug reports are in high demand, so get busy and let me know of any potential hiccups.
...please note that some file links on the webpage don't work (because the file naming scheme has been altered).
Zooming is cool! There are, however, some objects which don't scale appropriately - the red GOP box is one. (See attached screenshot)
András
...please note that some file links on the webpage don't work (because the file naming scheme has been altered).
Oops, thanks for the bug report! Will fix that shortly (and while at it I am already uploading 20120305 version which makes tooltips even more robust)
Zooming is cool! There are, however, some objects which don't scale appropriately - the red GOP box is one. (See attached screenshot)
That is because GOP objects are of user-selected size, just like iemgui objects (which also do not resize for the same reason). Font based zooming simply changes font sizes and repositions all objects to be still in the same relation to each other. True zooming (ala desiredata), while desireable (no pun intended) is at this point IMO too much work for too little gain. Entire internals need to be addressed because the object mapping and selection logic is split between the toolkit and c which makes the entire thing a nightmare. I think this is a good compromise that should work in the interim. I am also convinced that instead of having one monolithic pd that can do both editor and headless operation, we really need 2 instances. One that is based essentially off of libpd and another that is a robust editor with none of the convoluted client server model between the editor and the engine itself that has made improving on the code so cumbersome
Hope this helps!
András
2012/3/6 Ivica Ico Bukvic ico@vt.edu
[...]**Zooming is cool! There are, however, some objects which don't scale appropriately - the red GOP box is one. (See attached screenshot)****
That is because GOP objects are of user-selected size, just like iemgui objects (which also do not resize for the same reason). Font based zooming simply changes font sizes and repositions all objects to be still in the same relation to each other. True zooming (ala desiredata), while desireable (no pun intended) is at this point IMO too much work for too little gain. Entire internals need to be addressed because the object mapping and selection logic is split between the toolkit and c which makes the entire thing a nightmare. I think this is a good compromise that should work in the interim. I am also convinced that instead of having one monolithic pd that can do both editor and headless operation, we really need 2 instances. One that is based essentially off of libpd and another that is a robust editor with none of the convoluted client server model between the editor and the engine itself that has made improving on the code so cumbersome…****
Hope this helps!****
(A late) Thanks for the explanation! So am I getting your vision right: to have a sort of 'server' which runs pd patches and an editor which only edits patches and submits them to the server to run? Plus I guess dynamic patching and changes graphical objects' attributes which will make it all more complicated...?
András
(A late) Thanks for the explanation! So am I getting your vision right: to have a sort of 'server' which runs pd patches and an editor which only edits patches and submits them to the server to run? Plus I guess dynamic patching and changes graphical objects' attributes which will make it all more complicated...?
András
Actually I am thinking more of two separate instances. One is headless server if you like, the other one is fully integrated system/editor that also encapsulates the server. This is because as soon as you start transporting things over a socket, any busy gui stuff, particularly redrawing large arrays, becomes a terribly slow feat. OTOH, the system would still have to be threaded to prevent gui from messing with the engine, so to say. I think this is essentially how Max works but I honestly don't know for sure.
HTH
Best wishes,
Ico
Le 2012-03-06 à 00:42:00, Ivica Ico Bukvic a écrit :
Font based zooming simply changes font sizes and repositions all objects to be still in the same relation to each other. True zooming (ala desiredata), while desireable (no pun intended)
Well, in desiredata, puns were intended. The name was made from desiderata, a latin word to allude to todo-lists and wish-lists.
is at this point IMO too much work for too little gain.
Curiously, I would have said exactly that about your fontsize thing. I would say that true zooming is the only way to go, and anything else distracts by creating bigger complications.
we really need 2 instances. One that is based essentially off of libpd and another that is a robust editor with none of the convoluted client server model between the editor and the engine itself that has made improving on the code so cumbersome…
You want to replace the current client-server model by what exactly ? Most likely another kind of client-server model ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Curiously, I would have said exactly that about your fontsize thing. I would say that true zooming is the only way to go, and anything else distracts by creating bigger complications.
Well, code-wise it is not. I simply change font size and automate stretch values and don't worry about GOP objects because GOP design is in part conceived around specific pixel size. Resizing them could potentially wreak complete havoc on the organization of visual data inside them.
To complicate matters further, tcl/tk treats canvas text differently than canvas objects (vectors), so a true zoom can be never achieved completely accurately. Imagine for instance having an iemgui object that has a label with a font size of 16 and the rest of the patch using font size 10. When you resize things one step up (since you are limited by what font sizes are feasible, meaning zoom factor is restricted to workable font sizes) from 10 to 12, you are still severely limited by tcl/tk--while the increase in 120% can easily translate to vectors using canvas scale call, it does not account for images, or outlier font sizes (120% of a font size 16 is 19.2 and unless I am missing something there is no such font size possible inside tcl/tk). So, I do think this is the most sensible way of dealing with this until pd-l2ork shifts to a different toolkit altogether that is not so font-centric.
BTW, Pd-l2ork currently has a way to resize everything that is disabled because resizing of the aforesaid issue, as well as the fact that everything on tcl/tk's side of things does not account for all the changes necessary on C side of things that would require updating each object's location and size and updating its C-based structs that contain that info. This is why in part client-server separation (for the editor) makes little sense when so much of the client is already contained inside the server...
we really need 2 instances. One that is based essentially off of libpd and another that is a robust editor with none of the convoluted client server model between the editor and the engine itself that has made improving on the code so cumbersome
You want to replace the current client-server model by what exactly ? Most likely another kind of client-server model ?
Yes, but one that does not use sockets to communicate critical data and as such is severely limited in its performance, nor is it severely limited by the toolkit.
Best wishes,
Ico
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: 'Mathieu Bouchard' matju@artengine.ca Cc: pd-list@iem.at Sent: Tuesday, March 27, 2012 2:32 PM Subject: Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
Curiously, I would have said exactly that about your fontsize thing. I would say that true zooming is the only way to go, and anything else distracts by creating bigger complications.
Well, code-wise it is not. I simply change font size and automate stretch values and don't worry about GOP objects because GOP design is in part conceived around specific pixel size. Resizing them could potentially wreak complete havoc on the organization of visual data inside them.
To complicate matters further, tcl/tk treats canvas text differently than canvas objects (vectors), so a true zoom can be never achieved completely accurately. Imagine for instance having an iemgui object that has a label with a font size of 16 and the rest of the patch using font size 10. When you resize things one step up (since you are limited by what font sizes are feasible, meaning zoom factor is restricted to workable font sizes) from 10 to 12, you are still severely limited by tcl/tk--while the increase in 120% can easily translate to vectors using canvas scale call, it does not account for images, or outlier font sizes (120% of a font size 16 is 19.2 and unless I am missing something there is no such font size possible inside tcl/tk). So, I do think this is the most sensible way of dealing with this until pd-l2ork shifts to a different toolkit altogether that is not so font-centric.
What does font-centric mean?
BTW, Pd-l2ork currently has a way to resize everything that is disabled because resizing of the aforesaid issue, as well as the fact that everything on tcl/tk's side of things does not account for all the changes necessary on C side of things that would require updating each object's location and size and updating its C-based structs that contain that info. This is why in part client-server separation (for the editor) makes little sense when so much of the client is already contained inside the server...
we really need 2 instances. One that is based essentially off of libpd and another that is a robust editor with none of the convoluted client server model between the editor and the engine itself that has made improving on the code so cumbersome…
You want to replace the current client-server model by what exactly ? Most likely another kind of client-server model ?
Yes, but one that does not use sockets to communicate critical data and as such is severely limited in its performance, nor is it severely limited by the toolkit.
Best wishes,
Ico
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: 'Mathieu Bouchard' matju@artengine.ca Cc: pd-list@iem.at Sent: Tuesday, March 27, 2012 2:32 PM Subject: Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote
external now available
Curiously, I would have said exactly that about your fontsize
thing. I
would say that true zooming is the only way to go, and anything
else
distracts by creating bigger complications.
Well, code-wise it is not. I simply change font size and automate
stretch values
and don't worry about GOP objects because GOP design is in part
conceived
around specific pixel size. Resizing them could potentially wreak
complete havoc
on the organization of visual data inside them.
To complicate matters further, tcl/tk treats canvas text differently
than canvas
objects (vectors), so a true zoom can be never achieved completely
accurately.
Imagine for instance having an iemgui object that has a label with a
font size
of 16 and the rest of the patch using font size 10. When you resize
things one
step up (since you are limited by what font sizes are feasible,
meaning zoom
factor is restricted to workable font sizes) from 10 to 12, you are
still
severely limited by tcl/tk--while the increase in 120% can easily
translate to
vectors using canvas scale call, it does not account for images, or
outlier font
sizes (120% of a font size 16 is 19.2 and unless I am missing
something there is
no such font size possible inside tcl/tk). So, I do think this is the
most
sensible way of dealing with this until pd-l2ork shifts to a
different toolkit
altogether that is not so font-centric.
What does font-centric mean?
It means that zoom levels news to be driven by integer font sizes as tcl/tk canvas is incapable of displaying non-int font sizes. This is why the pd object drawing mechanism first queries font width and height to decide how big of a box to draw. It is simply incapable of doing out the other way around.
BTW, Pd-l2ork currently has a way to resize everything that is
disabled because
resizing of the aforesaid issue, as well as the fact that everything
on
tcl/tk's side of things does not account for all the changes
necessary on C
side of things that would require updating each object's location and
size
and updating its C-based structs that contain that info. This is why
in part
client-server separation (for the editor) makes little sense when so
much of the
client is already contained inside the server...
we really need 2 instances. One that is based essentially off of
libpd
and another that is a robust editor with none of the convoluted
client
server model between the editor and the engine itself that has
made
improving on the code so cumbersome…
You want to replace the current client-server model by what
exactly ?
Most likely another kind of client-server model ?
Yes, but one that does not use sockets to communicate critical data
and as such
is severely limited in its performance, nor is it severely limited by
the
toolkit.
Best wishes,
Ico
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-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
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: Jonathan Wilkes jancsika@yahoo.com; 'Mathieu Bouchard' matju@artengine.ca Cc: "pd-list@iem.at" pd-list@iem.at Sent: Tuesday, March 27, 2012 6:57 PM Subject: Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: 'Mathieu Bouchard' matju@artengine.ca Cc: pd-list@iem.at Sent: Tuesday, March 27, 2012 2:32 PM Subject: Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote
external now available
Curiously, I would have said exactly that about your fontsize
thing. I
would say that true zooming is the only way to go, and anything
else
distracts by creating bigger complications.
Well, code-wise it is not. I simply change font size and automate
stretch values
and don't worry about GOP objects because GOP design is in part
conceived
around specific pixel size. Resizing them could potentially wreak
complete havoc
on the organization of visual data inside them.
To complicate matters further, tcl/tk treats canvas text differently
than canvas
objects (vectors), so a true zoom can be never achieved completely
accurately.
Imagine for instance having an iemgui object that has a label with a
font size
of 16 and the rest of the patch using font size 10. When you resize
things one
step up (since you are limited by what font sizes are feasible,
meaning zoom
factor is restricted to workable font sizes) from 10 to 12, you are
still
severely limited by tcl/tk--while the increase in 120% can easily
translate to
vectors using canvas scale call, it does not account for images, or
outlier font
sizes (120% of a font size 16 is 19.2 and unless I am missing
something there is
no such font size possible inside tcl/tk). So, I do think this is the
most
sensible way of dealing with this until pd-l2ork shifts to a
different toolkit
altogether that is not so font-centric.
What does font-centric mean?
It means that zoom levels news to be driven by integer font sizes as tcl/tk canvas is incapable of displaying non-int font sizes. This is why the pd object drawing mechanism first queries font width and height to decide how big of a box to draw. It is simply incapable of doing out the other way around.
Ah, I understand. I forgot about that aspect of tk.
-Jonathan
Hello,
while trying to compile the new disis_wiimote with the L2Ork version of CWiid library on ubuntu 10.04 against Pd extended 0.42.5 or Pd 0.43.2, I get "disis_wiimote.pd_linux: undefined symbol: sys_flushtogui" when trying to load the help patch disis_wiimote-help.pd and the object is not created. Any idea why ?
thanks Benjamin
On 05/07/2012 07:06 PM, Benjah @ 01xy.fr wrote:
Hello,
while trying to compile the new disis_wiimote with the L2Ork version of CWiid library on ubuntu 10.04 against Pd extended 0.42.5 or Pd 0.43.2, I get "disis_wiimote.pd_linux: undefined symbol: sys_flushtogui" when trying to load the help patch disis_wiimote-help.pd and the object is not created. Any idea why ?
Because pd-l2ork exposes this function to externals and default pd doesn't. Current disis_wiimote only works with pd-l2ork and with L2Ork version of CWiid library. In return, it provides features that no other FOSS external can, such as passthrough mode support and xrun-free bidirectional communication.
HTH
Ico
thanks Benjamin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 05/07/2012 07:33 PM, Ivica Ico Bukvic wrote:
On 05/07/2012 07:06 PM, Benjah @ 01xy.fr wrote:
Hello,
while trying to compile the new disis_wiimote with the L2Ork version of CWiid library on ubuntu 10.04 against Pd extended 0.42.5 or Pd 0.43.2, I get "disis_wiimote.pd_linux: undefined symbol: sys_flushtogui" when trying to load the help patch disis_wiimote-help.pd and the object is not created. Any idea why ?
Because pd-l2ork exposes this function to externals and default pd doesn't. Current disis_wiimote only works with pd-l2ork and with L2Ork version of CWiid library. In return, it provides features that no other FOSS external can, such as passthrough mode support and xrun-free bidirectional communication.
HTH
Ico
Forgot to mention, if using pd-l2ork is not an option (which it shouldn't be, at least not on Linux since it is 100% backwards compatible), you could comment out the line in the source containing the said call as it is more of a cosmetic thing (it posts message to console before trying to connect, otherwise, the text "press 1 and 2 simultaneously to connect..." due to threaded design ends up being posted after the wiimote has connected.
HTH
thanks Benjamin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On May 7, 2012, at 7:41 PM, Ivica Ico Bukvic wrote:
On 05/07/2012 07:33 PM, Ivica Ico Bukvic wrote:
On 05/07/2012 07:06 PM, Benjah @ 01xy.fr wrote:
Hello,
while trying to compile the new disis_wiimote with the L2Ork version of CWiid library on ubuntu 10.04 against Pd extended 0.42.5 or Pd 0.43.2, I get "disis_wiimote.pd_linux: undefined symbol: sys_flushtogui" when trying to load the help patch disis_wiimote-help.pd and the object is not created. Any idea why ?
Because pd-l2ork exposes this function to externals and default pd doesn't. Current disis_wiimote only works with pd-l2ork and with L2Ork version of CWiid library. In return, it provides features that no other FOSS external can, such as passthrough mode support and xrun-free bidirectional communication.
HTH
Ico
Forgot to mention, if using pd-l2ork is not an option (which it shouldn't be, at least not on Linux since it is 100% backwards compatible), you could comment out the line in the source containing the said call as it is more of a cosmetic thing (it posts message to console before trying to connect, otherwise, the text "press 1 and 2 simultaneously to connect..." due to threaded design ends up being posted after the wiimote has connected.
Why do you think that this can only be done by exposing sys_flushtogui()? My guess is that this can be done using the current public API, but I'd to know more about the issue to make a concrete suggestion.
There are a number of objects that handle bidirectional communication with hardware and they don't need sys_flushtogui(). [comport] and [hidio] come to mind. Then there are the network objects, which also handle bidirectional communication.
.hc
Why do you think that this can only be done by exposing sys_flushtogui()? My guess is that this can be done using the current public API, but I'd to
know
more about the issue to make a concrete suggestion.
Indeed... To make any suggestions, like the one below, you would need to look at the external's behavior. In this case, connection is handled in the same thread as pd which means the thread freezes until wiimote connects. Because connection happens immediately after requesting the posting of a message "please press 1+2 buttons on a wiimote to connect" (which I would argue is rather important bit of information for a user), the message never reaches the gui because the thread freezes waiting on the Bluetooth stack to report that the connection has succeeded/failed. Flushtogui placed in between the post() call and the connect() call allows for the said message to be indeed displayed before the pairing takes place. If you can think of a better way to do this I'd certainly appreciate suggestions.
As for bidirectionality of communication, this has nothing to do with examples listed below. Rather, on lower-powered cpus (e.g. Atom netbooks) request to enable rumble on a wiimote most of the times results in an xrun. disis_wiimote handles this and other thread-unsafe actions in a separate thread so that one can send as many rumble/led/etc. requests back to wiimote without that having to result in an xrun.
There are a number of objects that handle bidirectional communication with hardware and they don't need sys_flushtogui(). [comport] and [hidio] come to mind. Then there are the network objects, which also handle
bidirectional
communication.
On May 10, 2012, at 1:45 PM, Ivica Ico Bukvic wrote:
Why do you think that this can only be done by exposing sys_flushtogui()? My guess is that this can be done using the current public API, but I'd to
know
more about the issue to make a concrete suggestion.
Indeed... To make any suggestions, like the one below, you would need to look at the external's behavior. In this case, connection is handled in the same thread as pd which means the thread freezes until wiimote connects. Because connection happens immediately after requesting the posting of a message "please press 1+2 buttons on a wiimote to connect" (which I would argue is rather important bit of information for a user), the message never reaches the gui because the thread freezes waiting on the Bluetooth stack to report that the connection has succeeded/failed. Flushtogui placed in between the post() call and the connect() call allows for the said message to be indeed displayed before the pairing takes place. If you can think of a better way to do this I'd certainly appreciate suggestions.
It sounds to me like the issue in the thread programming. Using threads in Pd externals is tricky since the thread has to sync up with Pd, which uses an entirely different kind of scheduling than threads.
Why not handle the connect in the other thread? Or even better, maybe there is a non-blocking way to do it where [wiimote] registers a callback, then sends the connect message, and carries on normally.. Then once the wiimote finished connecting, cwiid calls the callback in Pd, and Pd registers the wiimote as connected.
.hc
As for bidirectionality of communication, this has nothing to do with examples listed below. Rather, on lower-powered cpus (e.g. Atom netbooks) request to enable rumble on a wiimote most of the times results in an xrun. disis_wiimote handles this and other thread-unsafe actions in a separate thread so that one can send as many rumble/led/etc. requests back to wiimote without that having to result in an xrun.
There are a number of objects that handle bidirectional communication with hardware and they don't need sys_flushtogui(). [comport] and [hidio] come to mind. Then there are the network objects, which also handle
bidirectional
communication.
On 5/11/12 10:24 AM, Hans-Christoph Steiner wrote:
On May 10, 2012, at 1:45 PM, Ivica Ico Bukvic wrote:
Why do you think that this can only be done by exposing sys_flushtogui()? My guess is that this can be done using the current public API, but I'd to
know
more about the issue to make a concrete suggestion.
Indeed... To make any suggestions, like the one below, you would need to look at the external's behavior. In this case, connection is handled in the same thread as pd which means the thread freezes until wiimote connects. Because connection happens immediately after requesting the posting of a message "please press 1+2 buttons on a wiimote to connect" (which I would argue is rather important bit of information for a user), the message never reaches the gui because the thread freezes waiting on the Bluetooth stack to report that the connection has succeeded/failed. Flushtogui placed in between the post() call and the connect() call allows for the said message to be indeed displayed before the pairing takes place. If you can think of a better way to do this I'd certainly appreciate suggestions.
It sounds to me like the issue in the thread programming. Using threads in Pd externals is tricky since the thread has to sync up with Pd, which uses an entirely different kind of scheduling than threads.
Yes, and that's in part why options are rather limited as to how to handle this issue.
Why not handle the connect in the other thread? Or even better, maybe there is a non-blocking way to do it where [wiimote] registers a callback, then sends the connect message, and carries on normally.. Then once the wiimote finished connecting, cwiid calls the callback in Pd, and Pd registers the wiimote as connected.
.hc
That would be a lot harder to pull off as the current design is where the secondary thread only receives cues to do things, it does not send anything back. In the design you suggested (and which BTW I already considered before) the secondary thread would also have to return something to the main thread (namely pointer to the wiimote instance as cwiid instantiates wiimote struct and supporting variables at connection and destroys them when the wiimote disconnects). This means either having another entirely independent thread that exits as soon as the wiimote connects returning the object or having some seriously ugly code that tries to notify main thread when the wiimote has been fully instantiated. Between that and exposing one call (which is AFAIK benign to use in this context), I'd call with the exposing the call.
Ico
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Ivica Ico Bukvic ico@vt.edu Cc: pd-list@iem.at Sent: Tuesday, March 27, 2012 11:45 AM Subject: Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
Le 2012-03-06 à 00:42:00, Ivica Ico Bukvic a écrit :
Font based zooming simply changes font sizes and repositions all objects to
be still in the same relation to each other. True zooming (ala desiredata), while desireable (no pun intended)
Well, in desiredata, puns were intended. The name was made from desiderata, a latin word to allude to todo-lists and wish-lists.
is at this point IMO too much work for too little gain.
Curiously, I would have said exactly that about your fontsize thing. I would say that true zooming is the only way to go, and anything else distracts by creating bigger complications.
I don't agree. The pd-extended/vanilla font dialog is good for choosing an initial font size, and _nearly_ useless for changing font sizes. Pd-l2ork font dialog is good for choosing an initial font size, perfectly fine for changing font sizes when normal text objects are all that is in the patch, somewhat useful for changing font size in a patch mixed with text objects and iemguis, and only completely useless when changing font size for a patch in which only iemguis are visible.
This isn't just theoretical. I wanted to read a help patch in a larger font, and on pd-l2ork I just increased the font size and stretched the patch window to be bigger. On pd-extended/vanilla the text objects would have collided with a bigger font and would have been illegible.
-Jonathan
we really need 2 instances. One that is based essentially off of libpd and
another that is a robust editor with none of the convoluted client server model between the editor and the engine itself that has made improving on the code so cumbersome…
You want to replace the current client-server model by what exactly ? Most likely another kind of client-server model ?
| 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
Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Ivica Ico Bukvic ico@vt.edu Cc: pd-list@iem.at Sent: Tuesday, March 27, 2012 11:45 AM Subject: Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote
external now available
Le 2012-03-06 à 00:42:00, Ivica Ico Bukvic a écrit :
Font based zooming simply changes font sizes and repositions all
objects to
be still in the same relation to each other. True zooming (ala
desiredata),
while desireable (no pun intended)
Well, in desiredata, puns were intended. The name was made from desiderata, a latin word to allude to todo-lists and wish-lists.
is at this point IMO too much work for too little gain.
Curiously, I would have said exactly that about your fontsize thing.
I would say
that true zooming is the only way to go, and anything else distracts
by creating
bigger complications.
I don't agree. The pd-extended/vanilla font dialog is good for choosing an initial font size, and _nearly_ useless for changing font sizes. Pd-l2ork font dialog is good for choosing an initial font size, perfectly fine for changing font sizes when normal text objects are all that is in the patch, somewhat useful for changing font size in a patch mixed with text objects and iemguis, and only completely useless when changing font size for a patch in which only iemguis are visible.
But even this is debatable if you consider that the zoom tool is actually a patcher font size change tool (not gui zoom tool) that can be misrepresented as a zoom tool. In this case it makes no sense to resize iemgui objects when they are explicitly designed as gui objects whose properties are adjusted independently of core fonts. This is why also true zooming is impossible to do on tcl/tk canvas that has both vectors and fonts. And this is exactly why I chose not to bother with this feature.
This isn't just theoretical. I wanted to read a help patch in a larger font, and on pd-l2ork I just increased the font size and stretched the patch window to be bigger. On pd-extended/vanilla the text objects would have collided with a bigger font and would have been illegible.
-Jonathan
we really need 2 instances. One that is based essentially off of
libpd and
another that is a robust editor with none of the convoluted client
server model
between the editor and the engine itself that has made improving on
the code so
cumbersome…
You want to replace the current client-server model by what exactly ?
Most
likely another kind of client-server model ?
| 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
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
This release includes backported font-sizing logic, minor improvements to the tooltips engine, and a couple of cosmetic bug-fixes. For a complete list of changes please see the pd-l2ork git changelog (https://github.com/pd-l2ork).
L2Ork supports builds for both 32-bit and 64-bit Linux systems and can be downloaded from the usual place:
http://l2ork.music.vt.edu/main/?page_id=56
As usual, bug reports are in high demand, so get busy and let me know of any potential hiccups.
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: p1k53l workshop piksel@piksel.no Cc: pd-list@iem.at; linux-audio-user@lists.linuxaudio.org Sent: Sunday, March 18, 2012 6:24 PM Subject: [PD] ANN: pd-l2ork v.20120317 now available
T his release includes backported font-sizing logic,
Great-- the fonts look right in Debian Wheezy now.
One question, though-- given that the optimal patch-zooming functionality is not possible with Tk without a lot of work, would it be better to actually resize any iemguis in the patch? They all have methods for setting the size, and it wouldn't change the functionality of the objects.
Also, could you map zoom-in to <ctrl-+> and <ctrl-=> and zoom-out to <ctrl-minus-key>?
-Jonathan
minor improvements to the tooltips engine, and a couple of cosmetic bug-fixes. For a complete list of changes please see the pd-l2ork git changelog (https://github.com/pd-l2ork).
L2Ork supports builds for both 32-bit and 64-bit Linux systems and can be downloaded from the usual place:
http://l2ork.music.vt.edu/main/?page_id=56
As usual, bug reports are in high demand, so get busy and let me know of any potential hiccups.
-- 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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Great-- the fonts look right in Debian Wheezy now.
Good to hear :-) You should've reported this earlier--I did not know this was an issue until I tried Ubuntu 12.04 beta :-)
One question, though-- given that the optimal patch-zooming functionality is not possible with Tk without a lot of work, would it be better to actually resize any iemguis in the patch? They all have methods for setting the size, and it wouldn't change the functionality of the objects.
Well, I did some thinking about this and here's what I've come up with so far:
Since iemgui objects are customized as "gui" objects, they should be treated separately from the rest of the font matters since they are indeed treated as such when it comes to editing/integrating them into a gui. This is particularly true for tight GOP objects that would go entirely out of whack unless we implement a truly global zoom rather than just a font change. So, this would be an argument for not touching them. On the other hand, this is not entirely true as they do pull current font size at creation time but do not react to latter changes (so this is definitely argument in favor of what you are proposing). So, I am a bit torn on them for the time being as changing them would mess everything else up (e.g. aforesaid GOP objects), but on the other hand there is a precedent for them being adjustable. For this reason, I am simply imagining that at some point down the road the font sizing will be replaced by a genuine zoom (which I already implemented from a visual perspective except that I did not account for the object location changes that then mess everything up inside the editor).
Also, could you map zoom-in to <ctrl-+> and <ctrl-=> and zoom-out to <ctrl-minus-key>?
Good idea.
-Jonathan
minor improvements to the tooltips engine, and a couple of cosmetic bug-fixes. For a complete list
of
changes please see the pd-l2ork git changelog
(https://github.com/pd-l2ork).
L2Ork supports builds for both 32-bit and 64-bit Linux systems and can be downloaded from the usual place:
http://l2ork.music.vt.edu/main/?page_id=56
As usual, bug reports are in high demand, so get busy and let me know
of any
potential hiccups.
-- 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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
András Murányi -
Benjah ＠ 01xy.fr -
Hans-Christoph Steiner -
Ivica Ico Bukvic -
Jonathan Wilkes -
Mathieu Bouchard