[PD] why units per pixel: -1 by default on subpatches?

Christof Ressi info at christofressi.com
Mon Apr 4 14:41:49 CEST 2022


> The order of the bounds message is: "<xmin>, <ymax>, <xmax>, <ymin>".
>
> This makes more sense as a pair of top and bottom coordinates and 
> maybe we can change the window dialog accordingly, but I also think 
> that is quite confusing. The message seems inverted as it'd make more 
> sense to me to something like "<xmin>, <ymin>, <xmax>, <ymax>" or 
> "<xmin>, <xmax>, <ymin>, <ymax>" in both the 'bounds' message and the 
> properties window.

Yes, the order might not be intuitive, but once you know it, I don't 
think there's a problem.

Note that for non-GOP patches, the last two arguments are effectively 
ignored. To set the x-pixel-size to 2 and the y-pixel-size to 4, you 
would send [bound 2 4 0 0(.

Now, it would be nice if the last two arguments could be omitted. 
Currently, Pd would complain with an error. For this purpose, the 
current argument order is actually helpful.

Also note that the y-pixel-size argument is really inverted, so [bound 2 
4 0 0( actually sets the y-pixel size to -4. That part is really 
confusing, but we cannot change that. Instead we just need to document 
it properly.

> Not sure what to do besides creating a new message/method to replace 
> 'bounds'.
Just leave it as it is?
>
> There's a PR or a new message to set graph size ==> 
> https://github.com/pure-data/pure-data/pull/627 maybe it could also 
> set bounds... (?)

[goprect( is really about setting the GOP size and position. I 
explicitly do not want to add boundary/pixel-size arguments because we 
already have [bounds(.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20220404/8cf50a81/attachment.htm>


More information about the Pd-list mailing list