Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
- Original Message - > From: Ivica Ico Bukvic > To: Jonathan Wilkes ; 'Mathieu Bouchard' > > Cc: "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 wrote: > >> - Original Message - >> >>> From: Ivica Ico Bukvic >>> To: 'Mathieu Bouchard' >>> 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
Jonathan Wilkes wrote: > > > > >- Original Message - >> From: Mathieu Bouchard >> To: Ivica Ico Bukvic >> 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
Jonathan Wilkes wrote: >- Original Message - > >> From: Ivica Ico Bukvic >> To: 'Mathieu Bouchard' >> 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
- Original Message - > From: Ivica Ico Bukvic > To: 'Mathieu Bouchard' > 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 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
- Original Message - > From: Mathieu Bouchard > To: Ivica Ico Bukvic > 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 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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. 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
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. 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
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
(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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
2012/3/6 Ivica Ico Bukvic > [...]** > > > 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
...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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
> 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: > 1) tooltips > 2) 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! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
- Original Message - > From: Ivica Ico Bukvic > To: 'Jonathan Wilkes' ; 'p1k53l workshop' > ; pd-list@iem.at; linux-audio-u...@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: 1) tooltips 2) 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: 1) 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 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 - Original Message - > From: Ivica Ico Bukvic > To: pd-list@iem.at; linux-audio-u...@lists.linuxaudio.org; pik...@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 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
