Hello,

I am new to quick data
after playing a bit with the graphs, I realized it was not clipping data
rfft ouput data in a array for instance, and I had to scale it down
but what buggles me is that the rendered data goes way out of the graph rectangle with no clipping
is there a way to correct this ? is it for speed reason that clipping tests are not done ?

thanks

@phil123456 Hello Phil...
You can clip your data with [clip] or for audio [clip~] before it gets to the graph, or if you have "big" data that you want to see properly you can change the size / range (scale) of your graph in it's "right-click" "properties".....
As a graph is a graphical representation of the data it is usually thought a good thing that you can see all of the data, and that adjusting the scale to suit the data is "best?".........
David.

@whale-av: It seems more likely that the graph and garray code was written first, without realizing that clipping was needed.

Consider:

1. It's not just the dependent variable (i.e., y position) which can fall outside the bounds of the graph. If you try to change the x range for a 100-element array to be between 50 and 60, for example, the array will extend well past the graph's horizontal boundaries, too. So the dialog makes it seem like you can set the graph to view only a portion of an array when in fact that's not true.
2. Even for y-values, it's not just that they can be shown above or below the graph. For extreme values they can fall well beyond the canvas viewport, causing the vertical scrollbar to shrink so small that it becomes difficult to navigate the canvas anymore.
3. Even if you clipped the garray to fall within the left and right bounds of the graph, data structure arrays on a GOP will continue to be a problem because the user can set the x value for each element independently. But when they extend beyond the GOP you run into other problems, like failing to react to mouse events, or not getting redrawn properly.

It's difficult to address a lot of this because garrays are entangled in the data structure code for [plot]. So a fix in one area is likely to have unforeseen side-effects for the other.

@jancsika That is very probably true, but Pd was conceived (I believe) primarily for audio and composition, where audio should be confined to a +-1 y range (hence a new array has such limits). Vanilla objects that "shipped" with the first releases have -resize flags for the x range, and data structures have setsize which can be automated to fit requirements.
Of course that was necessary from the outset, as drawing millions of points will (as far as the user is concerned) "hang" Pd.
On the y axis though this is unnecessary as there is only one point, and it "should not" be outside the +-1 range........... unless there is a bad mistake in the patch then working with audio "y" is unlikely to be much outside that range.
It is true that arrays and graphs are not very easy or pretty. An abstraction with auto-range and all the x-y ticks in place would be great, but you would end up with a graph that is constantly changing, as it cannot "know" what is going to be thrown at it........ and so you would have no idea what you are looking at. We have to do some of the work ourselves, and we were just given the basic tools to do "anything" that we wish..........
To view only a part of your data you would have to load only that part into the graph (using -skip and -maxsize)..... that is true. A movable window would be a useful tool (project for tomorrow!).
Is someone trying to build a daw again.......... there are very good free daws around already!
David.
(P.S. you can stop the drawing outside the graph by burying it under 2 levels of gop.)

@phil123456 Thank you for the question........ it has forced me to spend some time with arrays.
There is another message for graphing arrays that will be useful........ but it is not a "clip"...... and there are probably others......
"normalize" for the y axis
You can send the message [myarray normalize 2(
David.