Here is the combi patch. Just load it, no need to do anything, I've automated the scale knob.pongasoft wrote:This looks like a bug. If you have a way to reproduce I would take it.WongoTheSane wrote: Although I'm not 100% sure because it changes when moving the zoom knob (I was playing with a [-256...256] signal). Notice the fact the vertical lines are the same color as the clipping color.
...and the gif in case you don't see it with the patch:
Wait... I've just captured the above gif, and it got me thinking: it didn't happen before preview 7, so clipping is probably somehow involved in the problem. Is it possible that when the clipping is important enough, the slopes won't be slopes but just vertical lines (because they represent less than 37 samples @ zoom 100 for instance), and a part of those samples clip, so the line gets to be white? And that doesn't happen all the time because is depends where exactly the sample range falls on that slope? It's quite blurry in my mind, sorry if it's confusing... I'll try another way: it looks like the line gets the color property from the sample range it represents (which is logical somehow: the line does indeed represent X samples, and one or several of those samples clip, so the line should be white), while I would have expected only the graphics display to handle the clipping information (if (y==127 | y==-127) & value>clipping_threshold then color(y) = white, else red for all other values of y). But I don't know how the SDK works so I may be waaayyy off...pongasoft wrote:I tried really hard with the colors. I think the issue is that although I am painting lines with a solid color (no alpha!), with a regular line full red and a clipping line full white, the end result is a mix of the 2 colors most likely due to anti aliasing in the drawing calls (which unfortunately I have no control over ). I will play with it more to see if I can get better results.