Skip to content

standalone: input channel mapping still uses the repeat-last rule while output no longer does #561

Description

@defiantnerd

Situation

StandaloneHost::clapProcess() maps the device stream onto the plugin's busses in two places, and since #547 the two halves no longer follow the same rule.

Output (src/detail/standalone/standalone_host.cpp:258-280) — a mono bus is duplicated onto the first two device channels, anything else maps channel-for-channel, and every surplus device channel is silenced.

Input (src/detail/standalone/standalone_host.cpp:222-239) — unchanged, still repeat-last:

auto devChan = (ch < currentInputChannels) ? ch : currentInputChannels - 1;

so when the plugin's input bus is wider than the device, every surplus bus channel receives a copy of the device's last channel.

Why output changed

The Windows frontend now opens devices at their full channel count. Under the old repeat-last rule a stereo plugin on an 8-output interface put its right channel on outputs 3 through 8 — a hard-right signal on whatever those outputs feed, typically a cue mix or a second pair of monitors. Silencing the channels the plugin does not address is the only surprise-free behaviour, so that is what output does now.

Why input was deferred

The same reasoning does not transfer cleanly, and the risk profile is different:

  • Surplus channels on the input side are bus channels, not device channels. The duplicated signal stays inside the plugin and never reaches a physical output, so there is no equivalent of the cue-mix hazard that forced the output change.
  • For the common case the current rule is arguably correct: a mono capture device feeding a stereo input bus duplicates to both channels, which is usually what is wanted. Silencing the second channel instead would be a behaviour regression for that case.
  • What the right answer is for the wider cases — a 2-channel device into a 6-channel bus, say — depends on what plugins actually expect from a standalone host, and that was not something the 0.16 review was in a position to decide.

Changing it alongside the output fix would have meant shipping an unexamined behaviour change on the input path to buy symmetry, so it was left alone deliberately.

Open question

Decide whether input should adopt the output rule (map channel-for-channel, silence surplus bus channels, keeping mono-device duplication as a special case) or keep repeat-last, and document whichever is chosen at both call sites so the asymmetry is no longer silent.

Noted here because the code comment that recorded this deferral was removed when the 0.16 comment volume was trimmed, leaving the asymmetry in the tree with nothing to explain it.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions