openmixer — generated API reference
    Preparing search index...

    Function proposeAllocation

    • The AUTO shape: every pool floored at what is attached, inputChannels additionally floored at what is declared today and the desk's known topology, packed to the strip quantum, capped through the appliance.

      Deliberate asymmetries, each a declared fact rather than a convenience:

      • MAIN is carried across, never proposed. Its count is the console's cardinality (LR / LCR / mono), not a pool sized by demand — nothing "uses" a fraction of MAIN, and a proposal that quietly turned an LCR desk stereo would be reshaping the show's geometry under the word "optimal".
      • Banked tiers round UP to roundUpToQuantum. One matrix in use proposes four, because a tier never ends part-way through a block. MAIN is the one unbanked tier. EVERY OTHER POOL floors purely at what is attached — this is the spec's own worked example: fewer matrices, more channels, proposed in the same breath.
      • Input channels floor at MIN_INPUT_CHANNELS and at the DECLARED topology — see AllocationProposalInput.declaredInputChannels. Below that (nothing patched, nothing declared) the proposal still guesses SMALL, exactly as it always has: a desk with nothing plugged in is not owed the strips it happened to be built with.
      • A floor the DECLARED TOPOLOGY pushes past what is patched snaps UP to the next CONSOLE_PRESETS size (nextFittingPresetInputs) rather than an arbitrary quantum-rounded number — the desk that outgrew 64 (a box enrolled with nowhere free to patch yet) is offered 96, a named size a session-setup picker also offers, because accepting it is a whole-desk rebuild the operator picks from a catalog. A floor driven by PATCHED usage alone (the ordinary case, declaredInputChannels unset or already covered by what is patched) keeps the plain quantum-packed count, exactly as it always has.

      Parameters

      Returns AllocationProposal

      the proposal, the current shape, and what is attached