[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