EVERY TAP POINT ANY DESK MAY NAME — the catalogue, in canonical signal order.
Operator ruling 2026-08-23: "define all the possible tap points and just bind per console."
So the universe is declared ONCE, here, and a desk's set is a BINDING into it — an ordered
subset, never its own invention. Two desks that both offer a pre-fader feed are then offering
the SAME point under two labels, which is what makes a template a template instead of a second
vocabulary. A set that could mint its own ids would give two desks no common ground and put the
burden of reconciling them on every client that reads both.
The order here is THE signal order, and a binding may not permute it (bindTapPoints refuses).
That is what makes "post-fader before pre-fader" unrepresentable across the whole product
rather than merely per-set.
Why there is no Post-Insert-A / Post-Insert-B
They were feed points only while insert A occupied a FIXED SLOT. In this model an insert goes
wherever it is put, so a name defined relative to one denotes no fixed place in the path — and
that is precisely why mix_tap.h never captured them. A point must be somewhere before it can
be tapped. Post-All is the opposite case and stays: "after everything" is a real boundary
whatever is placed in front of it.
EVERY TAP POINT ANY DESK MAY NAME — the catalogue, in canonical signal order.
Operator ruling 2026-08-23: "define all the possible tap points and just bind per console." So the universe is declared ONCE, here, and a desk's set is a BINDING into it — an ordered subset, never its own invention. Two desks that both offer a pre-fader feed are then offering the SAME point under two labels, which is what makes a template a template instead of a second vocabulary. A set that could mint its own ids would give two desks no common ground and put the burden of reconciling them on every client that reads both.
The order here is THE signal order, and a binding may not permute it (
bindTapPointsrefuses). That is what makes "post-fader before pre-fader" unrepresentable across the whole product rather than merely per-set.Why there is no
Post-Insert-A/Post-Insert-BThey were feed points only while insert A occupied a FIXED SLOT. In this model an insert goes wherever it is put, so a name defined relative to one denotes no fixed place in the path — and that is precisely why
mix_tap.hnever captured them. A point must be somewhere before it can be tapped.Post-Allis the opposite case and stays: "after everything" is a real boundary whatever is placed in front of it.