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

2022-04-02 Thread Alexandre Torres Porres
Em sáb., 2 de abr. de 2022 às 17:47, João Pais 
escreveu:

> the problem is that when making new patches where height plays a role,
> unless you know the limits for your height and set your window accordingly,
> you'll always have to play around with the vertical slider for it to
> display correctly.
>
yes, but that works both ways, wether it is a positive of negative value.
It is also true for the horizontal dimension, if you don't know the width
it may get out of bounds and you need to resize. And there is no real issue
resizing the height of the window if the Y unit is "1", you just need to
understand where the origin is to understand what happens. You can resize
by dragging the top corners instead of the bottom ones also, so I don't get
the point behind this.

Also, I think I remember display errors in the windows when opening them,
> even if the canvas was saved with enough height; readjusting minimally the
> canvas height fixes it.
>

well, seems like a bug we need to fix

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


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

2022-04-02 Thread João Pais


Em sex., 1 de abr. de 2022 às 13:46, Miller Puckette  
escreveu:


Because when just making a patch the origin is conventionally top
left,
not bottom left.  So pixels count downward, and if you want "y" to
increase
as you go up, that's the opposite dorection.


Sure, but let me see if I get things straight. This is just meaningful 
for Data Structures, right? Cause if I change this in a "regular" 
canvas, I don't see any difference. But maybe I'm missing something.


all the "units per pixel" values only affect data structure scalars.


Now, I can see the difference is where to consider the origin (0/0 
coordinate), but I don't know what's the benefit besides maybe having 
a more intuitive expectation when resizing the window, right? Perhaps 
one could argue it also makes easier to know where to append objects 
on the canvas, but I'm not sure about that.


Anyway, I really think it makes it very confusing for setting and 
retrieving field values that represent the horizontal axis. In the 
Data Structures tutorial examples, like 02.getting.data, the height of 
the triangle is a negative number. This is particularly troublesome 
for arrays, cause we really expect that the higher the element is, the 
higher its value should be.


Just install a mirror on your desktop and look at your screen downward
through it, and you'll see 'y' increase upward when 'scale' is set
to 1 :)


Not sure if that fixes everything and this can be easily fixed by 
setting the "Y units per pixel" value to a positive number, like in 
the 07.sequencer examples, which, by the way, makes much more sense to 
follow the score.


I'm now revising the Data Structures tutorial in my documentation 
updates and would like to bring this discussion into attention. I have 
changed all the patches so the "Y" unit is set to positive values and 
have better documented how this works. But anyway, I really think it 
makes more sense for a default value that we have Y units set to "1".


the problem is that when making new patches where height plays a role, 
unless you know the limits for your height and set your window 
accordingly, you'll always have to play around with the vertical slider 
for it to display correctly. Also, I think I remember display errors in 
the windows when opening them, even if the canvas was saved with enough 
height; readjusting minimally the canvas height fixes it.


Unless that a window slider control method would be added to pdcontrol 
to complement such issues, which would anyway be a good idea - it would 
allow for lots of new GUI possibilities.


Joao
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list