Edit A Shape As A Shape Agent Skill

Give the control the shape of the value

Ten sliders show ten unrelated numbers and make the user picture the result. A plot shows the

result. The control should have the shape of the value it edits — and it should sit *in* the

settings list, because the user adjusts it while listening and every navigation step between them

and the curve is a step they take twice.

The skeleton is a draft, a raw pointer loop, and one commit:

var draft by remember { mutableStateOf<List<Float>?>(null) }
val shown = draft ?: bands

// The gesture handler is installed once, so it must not close over the bands of the composition
// that installed it — that is the flat placeholder, before the stored curve has loaded.
val currentBands by rememberUpdatedState(bands)
val commit by rememberUpdatedState(onBandsChange)

// Hands the curve back to the stored value once the commit has been through storage.
LaunchedEffect(bands) { draft = null }

Modifier.pointerInput(count) {
    awaitEachGesture {
        val down = awaitFirstDown(requireUnconsumed = false)
        var working = currentBands.withPointAt(down.position, size, count)
        draft = working
        down.consume()
        while (true) {
            val change = awaitPointerEvent().changes.firstOrNull() ?: break
            if (!change.pressed) break
            working = working.withPointAt(change.position, size, count)
            draft = working
            change.consume()
        }
        commit(working)          // one write per gesture
    }
}

Traps

The drag-gesture helper eats the first part of every gesture, including all of a tap. It waits

for the pointer to travel past a slop threshold before reporting anything, so a plain click on a

handle sets nothing at all and the first few pixels of a real drag are swallowed. On a plot the

press *is* the edit — the point under the finger should move on touch-down. That is why the raw

awaitEachGesture loop, not detectDragGestures.

Commit once per gesture, never per event. Every write here lands in storage and from there in

the audio engine, which typically drains and rebuilds its whole graph to take it. Applying per

pointer event does that at frame rate for the duration of a drag. The draft exists precisely so the

line can follow the finger without any of it reaching storage on the way.

A handler installed once holds the values from that composition forever. pointerInput does not

recompose with the enclosing function, so the lambda's captured bands is whatever existed when the

block was installed — typically the flat placeholder shown before the stored value has loaded. A

drag started from that stale copy commits it and wipes the saved shape. rememberUpdatedState

for every value the handler reads, including the callback.

Drop the draft when the stored value arrives, not at release. Clearing it in the release branch

snaps the curve back to its pre-drag shape for the length of the storage round trip, which reads as

the control rejecting the edit and then accepting it. LaunchedEffect(storedValue) { draft = null }

sequences it correctly with no timing assumption.

Key pointerInput on the layout, never on the value. pointerInput(bands) looks like the fix

for the stale-capture trap above and is much worse: the block is torn down and reinstalled the moment

the value changes, which is *every frame of the drag you are currently performing*. The gesture is

cancelled mid-stroke and the curve stops following the finger. Key it on the point count — the only

input that actually changes the gesture's geometry — and take the values through

rememberUpdatedState.

Produce a new list per update; do not mutate. The draft is read by a draw pass on a later frame,

so a list mutated in place changes underneath the frame that is drawing it. Building a fresh list

also gives you the place to normalise its length, so a value saved by a build with fewer points

still drags instead of throwing at the first index past the end.

Naive smoothing flattens the curve at every handle. Putting both control points of a segment on

the current point's own y makes the line leave and arrive horizontally, pushing the whole climb into

the middle of the gap — a row of bevelled steps rather than a curve. Aim each control point along

the direction set by a point's *neighbours* (Catmull-Rom converted to cubic Bézier) so the line

arrives at the slope the shape implies.

Then clamp the control points to their own segment's span, or the curve disobeys the user.

Catmull-Rom overshoots after a steep change and dips past a handle that was deliberately placed.

On an editor — as opposed to a chart — that is not a cosmetic wobble; it says the control did

something other than what it was told:

val lo = minOf(p1.y, p2.y); val hi = maxOf(p1.y, p2.y)
cubicTo(p1.x + (p2.x - p0.x) / 6f, (p1.y + (p2.y - p0.y) / 6f).coerceIn(lo, hi), …)

Scales and labels go beside the canvas, never inside it. Text drawn into the plot ends up under

the finger that is dragging. Once the axis lives in a gutter of its own, the labels below have to be

offset by the *same* gutter width — two places computing one number, so hoist it into a constant or

every label sits off its own gridline.

Assemble the readouts in Kotlin. "+12dB", "−15 dB", "03:00 – 04:00" are numbers plus units, and

a resource format string is the wrong place for padding, rounding and symbols — see

string-resource-format-limits. A string resource should join already-formatted pieces, or nothing

at all.

Keep the block on one surface. A curve, a trim slider and a reset button laid straight into a

settings list read as three unrelated rows; behind one container they read as one control, which is

what they are.

Verifying it

Measure the control rather than looking at it — bounds and write counts, not screenshots:

# every commit path — expect exactly one, at the end of the gesture loop
grep -rn --include='*.kt' 'commit(\|onBandsChange(' . | grep -v 'val commit'
# and no stale capture: one rememberUpdatedState per value the handler reads (here, 2)
grep -rn --include='*.kt' -B12 -A20 'pointerInput(' . | grep -c 'rememberUpdatedState'

Behaviourally, in this order — the first is the one people skip because it "isn't a drag":

• tap a single point, no movement, and assert the value changed;
• drag across the whole plot and assert exactly one write reached storage;
• open the screen and drag immediately, before the stored value has loaded, and assert the saved

curve is not replaced by the placeholder;

• set two adjacent points far apart and assert the rendered path never leaves the span between

them — that is the overshoot check, and it needs the path, not a screenshot.