[PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available

[Jonathan Wilkes]

----- Original Message -----

> From: Ivica Ico Bukvic <ico at vt.edu>
> To: 'Mathieu Bouchard' <matju at artengine.ca>
> Cc: pd-list at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>