Hi, I believe this must have been discussed before... it's surely known. I wonder why when you add a subpatch the 'scale' section has an inverted "-1" scale for the vertical axis. This is particularly bad for display data structures and needs to be corrected by hand.
Should I open a request to change this default parameter?
cheers
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.
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 :)
M
On Mon, Mar 28, 2022 at 10:34:37PM -0300, Alexandre Torres Porres wrote:
Hi, I believe this must have been discussed before... it's surely known. I wonder why when you add a subpatch the 'scale' section has an inverted "-1" scale for the vertical axis. This is particularly bad for display data structures and needs to be corrected by hand.
Should I open a request to change this default parameter?
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Em sex., 1 de abr. de 2022 às 13:46, Miller Puckette msp@ucsd.edu 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.
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".
cheers
M
On Mon, Mar 28, 2022 at 10:34:37PM -0300, Alexandre Torres Porres wrote:
Hi, I believe this must have been discussed before... it's surely known.
I
wonder why when you add a subpatch the 'scale' section has an inverted
"-1"
scale for the vertical axis. This is particularly bad for display data structures and needs to be corrected by hand.
Should I open a request to change this default parameter?
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Em sex., 1 de abr. de 2022 às 23:42, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sex., 1 de abr. de 2022 às 23:11, Alexandre Torres Porres < porres@gmail.com> escreveu:
I have changed all the patches so the "Y" unit is set to positive values
Many of them already were by the way, not only 7.sequencer
namely, all examples from 7.sequencer have positive values for "Y units per pixel". All but 8.selection
Em sex., 1 de abr. de 2022 às 13:46, Miller Puckette msp@ucsd.edu 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
Em sáb., 2 de abr. de 2022 às 17:47, João Pais jmmmpais@gmail.com 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
Em sáb., 2 de abr. de 2022 às 17:47, João Pais jmmmpais@gmail.com escreveu:
all the "units per pixel" values only affect data structure scalars.
Thanks for clarifying, here's another question: whenever we have "graph on parent" checked, the units per pixels get grayed out and it seems that this parameter is meaningless in this case, right? See ==> http://msp.ucsd.edu/Pd_documentation/fig8.6.jpg
Just making it extremely sure, cause I want to document these things.
Now, in this case, if we want to plot data structures, we have to set the proper range in "X range" and "Y Range". Now, this range is also only meaningful for Data Strucutres, and regular arrays in Pd are Data Structures scalars anyway... right?
So, in this case, when you create a subpatch and check the "graph on parent" box, you get the "Y range" from -1 to 1. This seems to be the correct order, where the first is the lower value, and the "X range" is in fact the same, the first value is the lower "x value". Well, this plots arrays and other scalars in the reverse order...
Now, if you put a "graph" or an "array" from the Put Menu or shortcuts, you get a default "Y range" from 1 to -1 and this plots the array in a meaningful way. But it is weird that the default is different for both cases.
I haven't checked the code and I'm confused. The documentation is not explicit. I'm guessing that the "Y range" is in fact from lower to higher as in the "X range" but we need to swap this to plot arrays correctly. In my view, this would be a bug, and related to the units per pixels issue.
The way I see it, if I create a subpatch and decide to make it a graph, it should default to the same values as putting an array or a graph. And if the values are inverted, I think the interface can be fixed by simply swapping the boxes values under the hood. And the dialog can change to reflect the changes and make it eplicity by including "lower" and "upper" before the boxes.
As for units per pixels issue, it'd make sense that the range would default to "1" for both, so it corresponds to how graphs work.
Am I making sense?
cheers
Em dom., 3 de abr. de 2022 às 19:18, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sáb., 2 de abr. de 2022 às 17:47, João Pais jmmmpais@gmail.com escreveu:
all the "units per pixel" values only affect data structure scalars.
Thanks for clarifying
Well, that is not actually true. Regular patch windows are affected by this, but only when you resize the window. If both are "1", objects will move if you resize the window from the bottom corners, so I can see why the default for all canvases should be 1 unit per pixel for "X" and -1 for "Y" by default.
It's easy to explain this and how you probably want it to be "1" for both in canvases used for Data Structures.
This settles it, but there's also this second issue I raised, that the default "Y" range is different if you create a subpatch and make it "Graph on Parent" and if you add a "graph" from the Put Menu (or shortcut). I think the default should be the same for both and that the default for graph makes more sense.
here's another question: whenever we have "graph on parent" checked, the units per pixels get grayed out and it seems that this parameter is meaningless in this case, right? See ==> http://msp.ucsd.edu/Pd_documentation/fig8.6.jpg
Just making it extremely sure, cause I want to document these things.
Now, in this case, if we want to plot data structures, we have to set the
proper range in "X range" and "Y Range". Now, this range is also only meaningful for Data Strucutres, and regular arrays in Pd are Data Structures scalars anyway... right?
I would still like to clarify this
I haven't checked the code and I'm confused. The documentation is not explicit. I'm guessing that the "Y range" is in fact from lower to higher as in the "X range" but we need to swap this to plot arrays correctly. In my view, this would be a bug, and related to the units per pixels issue.
I checked the code, I'm not all sure, but it seems that the Y range is intended to be "upper" and "lower" indeed. At least there seems to be an intended order in the "bounds" message, which I have documented and included in the reference for "garrays" (in canvas-help.pd).
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. Not sure what to do besides creating a new message/method to replace 'bounds'.
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... (?)
cheers
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(.
-
Alexandre Torres Porres -
Christof Ressi -
João Pais -
Miller Puckette