openmixer — generated API reference
    Preparing search index...

    Interface ResourceOptions

    What OPTIONS answers: the methods allowed and the per-field capabilities.

    interface ResourceOptions {
        allow?: readonly ResourceMethod[];
        fault?: ResourceFault;
        fields?: ReadonlyMap<string, FieldCapability>;
        instances?: readonly Readonly<Record<string, string | number>>[];
        ok: boolean;
        reason?: string;
        refusal?: Refusal;
    }
    Index
    allow? fault? fields? instances? ok reason? refusal?
    allow?: readonly ResourceMethod[]
    fault?: ResourceFault
    fields?: ReadonlyMap<string, FieldCapability>
    instances?: readonly Readonly<Record<string, string | number>>[]

    The entity's ADDRESS SPACE — every id that exists right now, straight from ConsoleResource.instances. Absent where the entity cannot enumerate, which is a different sentence from []: "I will not claim to know" versus "there are none".

    This is what makes the roster askable. The address codec parses and canonicalises but cannot enumerate — it can say input/33 is well formed, never that it exists — so before this the strip set reached clients only in the connected frame, and a client that wanted it any other way had to guess. Publishing it here puts it on the layer it belongs to: GET / says which entity TYPES exist, OPTIONS says what an instance MAY be, GET says what it IS.

    Per-ROW, not per-console, and that is the point: /channel/{kind}/{index}/fbs is input-only by contract, so its space is smaller than /fader's. The kind restrictions stop being folklore a client re-implements.

    ok: boolean
    reason?: string
    refusal?: Refusal

    The coded reason, on a fault — NO_INSTANCE / NOT_ADDRESSABLE for an absent address.

    Settings
    Member Visibility

    On This Page
    Properties