Feature request: first automation point should snap to the parameter's existing value
The new automation curves are a huge addition — thank you for finally shipping them. Two small gaps make them harder to use than they need to be:
1. The first point drawn in an empty lane should inherit the parameter's current value.
Right now, that point lands wherever my mouse happens to be on the Y axis. But when a lane is empty, the parameter already has a value — that flat line is showing it. There's no reason the first click should throw that value away. Nobody draws their first point intending to jump the parameter to a new level; if they do want that, they can drag the point after it's placed.
Example: I have a clap in a pattern and I want it to fade in up to 8.3 at the level I've already dialed in. To do that today I have to click a point in, hover it to read the value, and then nudge it back toward where the line already was — and I can't see how far off I am, because I have no reference for what the original value was. It's guesswork for something that should be automatic.
2. The automation lane should display the current value of the line.
Before any points exist, there's no numeric readout for what the flat line represents. You only get a value after you've placed a point and hover it — at which point the original value is already gone. A persistent readout on the lane (or on hover anywhere along the line) would solve this on its own.
Together these mean automation always starts from where you had things set, and you move from there. That's the workflow people are actually reaching for.
3. The automation lane should map its full vertical height to the parameter's actual range.
There's a large dead zone above the maximum value. I can drag the line up past 10.0 dB and it just keeps reading 10.0 dB — the pixels are there, they're clickable, and they do nothing. The gradient shading that marks the in-range area isn't a sufficient fix; it tells you where the real values are but doesn't stop you from working outside them, and it doesn't give those pixels back.
The top of the lane should be the parameter's maximum and the bottom should be its minimum. Nothing else. Right now a meaningful chunk of the window's vertical resolution is wasted, which directly costs precision — every point I place has fewer usable pixels behind it than it should, so accurate curves are harder to draw than they need to be. Stretching the range to fill the lane fixes that for free, without any new UI.
