[jlnstrk]

TL;DR: the Hyper Core settings commands edit hyper.video's participant layer, leave five settings to hyper.video by default, and apply each setting on its own.

Today, the simulator sets a Hyper Core participant's settings through the setters on window.hyper.settings.media. hypervideo/hyper.video#6017 and hypervideo/hyper.video#6020 moved those settings into the core's settings layers and removed the setters, so every settings command but the transport's fails against current hyper.video. The first failure also skips the rest of the settings that a participant joins with, so neither its transport nor its microphone and camera state apply.

The commands now use hyper.settings.client. Getters read the value that applies from its report, and setters edit the participant layer, where a participant keeps its own choices. The PR is stacked on #12: without it, every noise suppression that the simulator offers but none names an engine that hyper.video drops.

• Auto gain control is volume normalization, which the web app's "Automatically adjust volume" switch turns on and off. On sets the participant's own levels, else the default ones, as that switch does, and off sets null.
• Video constraints are resolution levels: 480p is P480, and none is null, no limit. The constraints take 4320p too, hyper.video's highest level.
• The defaults follow hyper.video: auto gain control, background blur, both video constraints and the track limit take default in the config, the CLI, --participant JSON and the TUI, and default to it. default unsets the setting in the participant layer, so that an admin's value for the session applies, else hyper.video's default.
• Noise suppression stays none by default, and the simulator keeps setting it, so that simulated participants run no model where hyper.video's web platform defaults to Hyper Voice.
• Each setting applies on its own: a failing one is logged, and the rest still apply. On a deployment older than hypervideo/hyper.video#6020, such as meet.hyper.video, the transport and the microphone and camera state apply, and only the settings edits fail.

hyper.video's defaults match what the simulator set before: volume normalization on with a 0dBFS target and a -38dBFS threshold, no background blur, and no resolution limits. Only the track limit's default differs: one track, where the simulator set no limit.

Cloudflare participants are out of scope, since their worker calls the removed setters itself. The simulator sends the worker hyper.video's defaults in place of default, except no track limit, and none in place of 4320p, which its schema lacks.

Follow-up: the transport stays on hyper.settings.sessionDebug.forceWebrtc, which hyper.video still has. A planned hyper.video change replaces that join option with a layered transport setting, and the simulator moves to it then.

The settings edits need hyper.video from hypervideo/hyper.video#6020 on, which latest.dev, PR previews and local stacks run. A participant without a track limit now encodes one track; pass --video-max-concurrent-tracks unlimited for every track. A config.yaml that the TUI saved keeps its explicit values until they say default. --auto-gain-control and --blur take true, false or default.