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

Ivica Ico Bukvic ico at vt.edu
Wed Mar 28 00:57:56 CEST 2012



Jonathan Wilkes <jancsika at yahoo.com> wrote:

>----- 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?

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 at 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



More information about the Pd-list mailing list