openmixer — generated API reference
    Preparing search index...

    Function servedTap

    • The ONE spelling a tap is SERVED as — the resolved TapPreset, or an explicit { position } unchanged.

      pre / post stay valid INPUT for ever: they are what the retiring verbs send and what an older client writes, and SendTapSpec accepts them by design. What they must not do is come back out. A row that echoes whichever spelling it happens to hold serves two vocabularies on one field, and a client cannot round-trip its own write — measured on the live rig 2026-08-16: PATCH {"tap":"Post-All"} read back 'post', while a mix-minus send on the same row read 'Post-Fader'. A tap picker rendering the row's own value cannot match it against the options it just offered.

      The two are not even the same point: post resolves to Post-All (after the whole chain, post-fader inserts included) and Post-Fader is the fader's own output, one stage earlier. So the collapse is not cosmetic — a reader comparing tap === 'post' is asking a question the answer cannot be trusted to mean.

      Accept many, serve one: contract exact, not more not less applied to a field's VALUE space rather than to its field set.

      Parameters

      Returns TapPreset | { position: number }