#LiveSoundRack Manual for Professionals

#Scope

LiveSoundRack is a Windows-based, server-authoritative live-audio rack host for ASIO, VST3, and CLAP workflows. Server Core owns the realtime audio path and all authoritative rack, routing, plugin, playback, record, console, and operational state. Windows Client and the browser Web UI are remote or local control surfaces.

This manual covers commissioning, operation, persistence, networking, performance, failure handling, and the current functional constraints that matter to a production engineer or system integrator.

Production rule: establish gain structure and routing with the downstream system muted or attenuated. Built-in test signals are continuous, plugin/state changes can alter level, and a wrong output assignment can immediately reach an ASIO destination.

#1. System model

#1.1 Authority and control surfaces

Server Core is the sole audio and state authority. It:

• opens the selected ASIO driver;
• receives physical inputs and produces physical outputs;
• constructs and switches prepared rack-processing graphs;
• owns rack/slot identities, routing, parameters, plugin state, sidechains, and PDC;
• runs playback decode and the virtual Playback L/R source;
• taps input/output channels for recording;
• stores console, preset, catalog, and session data;
• publishes state to connected clients.

Clients issue commands and render published state. Closing a Windows Client or browser does not normally stop the server audio path. Multiple clients share the same server state; every accepted command affects the same authoritative configuration.

#1.2 Executables

Normal server process tree:

LiveSoundRack.Server.exe
└─ LiveSoundRack.Server.Core.exe
   ├─ LiveSoundRack.Server.Web.exe
   └─ LiveSoundRack.Server.PluginHost.exe  [zero or more, according to isolation]

Directly launching internal executables bypasses normal supervision and is not the standard operator path.

#1.3 Public state synchronization

The control layer publishes five coherent state domains:

• Rack — rack structure, slots, parameters, rack metadata and controls;
• Routing — input/output route identities and destinations;
• Plugin — plugin catalog, scan state, isolation and plugin-related overlays;
• Playback — playlists, transport, analysis, gain/fade and selection state;
• Core — ASIO, settings, recording, license, system, server and shared operational state.

Clients bootstrap from checkpoints and remain current through typed deltas/replay. This permits multiple clients to reconnect without becoming the authority. An operator should still avoid simultaneous conflicting edits; server acceptance order determines the final result.

#1.4 Realtime boundary

The ASIO callback consumes prepared processing state. Control commands, file I/O, network I/O, catalog work, graph construction, plugin-state persistence, playback decode, and record-file writing occur outside the callback. Graph changes are prepared and then published to the realtime path at safe boundaries.

This architecture prevents ordinary control work from intentionally blocking the audio callback, but it does not remove physical limits. A plugin can still overrun its block, an ASIO driver can fail, isolated transport can underrun, and storage can fail to keep up with recording.

#2. Deployment and network design

#2.1 Single-host deployment

Run Server and Windows Client on the same Windows machine. The browser endpoint is:

http://127.0.0.1:21011

This removes external network dependencies for control and allows local Original Editors without remote preview transport. It also places UI, server, ASIO, plugin DSP, and optional shadow plugin work on one computer, so CPU/GPU scheduling and desktop interruptions must be tested.

#2.2 Dedicated server deployment

Run LiveSoundRack.Server.exe on a dedicated audio computer. Control it with Windows Client or Chrome from one or more machines on a private LAN.

Recommended production design:

• wired Ethernet rather than Wi-Fi for primary control;
• static address or DHCP reservation for the server;
• private VLAN or physically isolated switch when practical;
• Windows Firewall rules restricted to the intended profile/interface;
• stable switch power and redundant control path where the show requires it;
• known direct URL in addition to discovery.

#2.3 Web UI header controls

Chrome provides server-hosted downloads in this order: Client, then Plugin Editor Host. The Client app hides the top information row and starts at the main control tabs. The downloads are served by the selected LiveSoundRack server, so use only a trusted Server endpoint.

If the LiveSoundRack Client app cannot find the Server, it replaces the current screen with Server Not Found in Local Network. The normal screen returns after the Server is available on the same local network again.

Use ABOUT → UI Scale to choose 50%–150% in 10% steps. The default is 100%. The setting applies to the whole Web UI and resets to 100% when the page or Client window is reopened.

#2.4 Ports and bindings

Do not expose these ports directly to the public Internet. The built-in browser endpoint is HTTP. For control across an untrusted network, place the connection inside a VPN or an appropriately secured, tested network access design.

#2.5 Discovery limitations

UDP discovery may be blocked by:

• routed VLAN boundaries;
• Wi-Fi client isolation;
• host firewall policy;
• broadcast suppression;
• VPN adapter preference;
• multiple NIC metrics.

Discovery failure does not imply that TCP control is unavailable. Test the direct endpoint:

http://<server-private-address>:21011

#2.6 Multiple clients

All clients operate one ServerCore canonical state. Practical policy should define who owns ASIO/host settings, rack topology, playback, record, console changes, and restart/power actions.

The current shared-confirmation contract is server-authoritative:

1. The origin client requests a risky/destructive action.
2. ServerCore publishes one active prompt with a stable prompt identity and target metadata.
3. All connected App/Web clients render the same prompt.
4. The first valid response wins; stale or duplicate responses are rejected.
5. The prompt closes on every client.
6. The origin command continues at most once and revalidates its target immediately before execution.

This contract covers restart/power actions, isolation changes, destructive console/preset/playlist operations, rack/plugin replacement/reset, memory-pressure plugin adds, and several server-confirmed failure/rollback notices. Input validation, local transport/launch failures, name/file pickers, and problems that exist only on one workstation remain local.

Scalar controls use a pending-intent reconciliation layer. Command success alone does not remove the local presentation; the control remains at the requested value until the matching authoritative domain revision is admitted. Failure, disconnect, or session replacement clears the intent and restores the current server value. Structural rack mutations do not use optimistic synthetic topology; they render the admitted Rack/Routing state.

A client can reconnect through checkpoint and ordered Delta replay. Commands prepared against stale stable identities can be rejected and must be retried after resynchronization rather than being applied to an unintended rack or slot.

#3. Installation and first commissioning

#3.1 Prerequisites

• Supported Windows environment.
• Manufacturer ASIO driver and connected interface.
• Server-side VST3/CLAP binaries and licenses.
• Writable LiveSoundRack server directory.
• Sufficient CPU, RAM, storage throughput, and network capacity.
• A production power plan and Windows maintenance policy suitable for live use.

Production audio is not available without a working ASIO driver/device.

#3.2 Server startup

1. Connect and power the audio interface.
2. Start LiveSoundRack.Server.exe.
3. Confirm tray status and Server Core launch.
4. Connect Windows Client or Chrome.
5. Open SERVER and verify Server, Core, and Web states.
6. Keep downstream outputs muted before ASIO start.

#3.3 Main tabs

#4. SETUP — system and host controls

#4.1 CPU Monitor and memory pressure

CPU Monitor provides operational visibility into LiveSoundRack work. Use it during worst-case rehearsal, not only idle commissioning. Exercise the smallest intended ASIO buffer, all production racks and oversampling modes, isolation transport, playback decode/analysis, maximum record channel count, the selected console transition, and required editor sessions.

The RAM meter reports physical memory use for the whole Server PC on the existing one-second monitor cadence. Separately, ServerCore samples Windows system commit capacity and derives a pressure level:

The displayed percentage remains physical RAM; the pressure marker is based on the additional Windows commit-capacity diagnostic. This distinction prevents the public RAM value from silently changing meaning.

The visual pressure state and the Plugin Add gate are related but not identical. Before an add, App/Web uses the latest valid ServerCore commit measurement. If it is below 80%, or commit telemetry is unavailable, no memory confirmation is required. At 80% or above, App/Web prepares the server-owned shared confirmation; therefore the first valid 80–<95% reading can require confirmation before the orange marker has completed its two-sample Warning entry. A reading at or above 95% uses critical/error severity. NO cancels the add. YES permits the origin client to issue the actual add once, after the shared-prompt context and the server-side target are revalidated. The threshold does not create unsolicited modal prompts, automatically change isolation, or hard-block existing audio. Test this path under controlled conditions and keep operating headroom well below it.

#4.2 CPU Steering

The current UI intentionally exposes six operator work groups rather than every internal thread category:

A zero/empty mask means All CPUs (fallback). A multi-category panel displays Mixed when its source categories currently differ; Mixed is display-only. Selecting a mask writes one common value for the group.

Owned long-running LiveSoundRack threads reapply policy by generation at their wake/work boundaries. Plugin-scan child processes, WebHost/EditorHost-related owned processes, staged and active PluginHosts, the De-Feedback worker, and Live Audio owner paths are covered where the application owns the boundary. Third-party plugin-created threads inside an in-process plugin remain outside per-thread enforcement, and All Processes Except LSR is not a continuously enforced operating-system policy.

Use CPU Steering only with repeatable measurement. Poor placement can concentrate work on one logical core, increase cache contention, or starve driver/network tasks. Preserve a documented known-good mapping and retest after CPU topology, BIOS, Windows, driver, or plugin changes.

#4.3 Runtime priorities

SETUP provides four selectors:

Available values are Idle, Below Normal, Normal, Above Normal, High, and Realtime. Network/UI can display Mixed when its two internal categories differ; selecting a value unifies them. Priority changes affect scheduling competition and do not create CPU capacity.

Avoid indiscriminate High/Realtime settings. Starving input, USB, storage, network, licensing, or driver service threads can make the system less stable than the defaults. Change one category at a time, test full load, and record the result.

#Performance Power Plan

The LiveSound.App Performance Power Plan is an optional Windows power policy exposed in SETUP → SYSTEM beside Shutdown. It is OFF by default.

When enabled, LiveSoundRack saves the currently active Windows power plan, creates or reuses LiveSound.App Performance Plan, and activates it. When the feature is turned off after being enabled, the saved plan is restored. If that plan is no longer available, Windows Balanced is used as the safe fallback. While the feature is OFF, a power plan selected directly in Windows is not forcibly replaced.

The supported plan settings are applied to both AC and DC operation. These include display and standby timeouts set to Never, physical and Start menu power buttons set to Shutdown, USB Selective Suspend settings, Interrupt Boost settings, and processor settings corresponding to System Maximizer Extreme Overboost. Unsupported individual settings are skipped. The feature does not modify global Registry settings, WMI USB configuration, or hibernation settings.

Enabling the plan opens a shared Performance Power Plan confirmation on connected App/Web clients. Selecting Yes applies the change; selecting No leaves the feature disabled. Switching is allowed while ASIO is running, but the result should be tested under the complete intended workload because disabling the plan may immediately reduce available performance.

If System Maximizer Extreme Mode is detected, the control is shown as System Maximizer Extreme Mode, remains enabled, and cannot be changed from LiveSoundRack. Manage that state in System Maximizer.

#4.4 Start with Windows

When enabled, LiveSoundRack creates a Startup shortcut for LiveSoundRack.Server.exe in the current user's Windows Startup folder. Verify the correct Windows account, sign-in policy, interface readiness, and license availability.

#4.5 Remember settings

Remember settings is enabled by default. It preserves host/ASIO/operator choices required for restoration. Disabling it should be deliberate; automatic startup cannot restore configuration that was not retained.

#4.6 Scheduled reboot

Scheduled reboot executes at a configured local time. Enabling it requires the surrounding restoration path, including remembered settings, ASIO auto-start, and Start with Windows.

Commission the entire cycle:

1. Stop/finish recording before the scheduled time.
2. Confirm Windows reboots and the intended user context starts.
3. Confirm Server tray starts.
4. Confirm Core/Web start.
5. Confirm interface enumeration.
6. Confirm ASIO auto-start.
7. Confirm console/settings restoration.
8. Confirm plugin licensing and any Waves Prewarm behavior.
9. Confirm remote client reconnection.

Do not schedule a reboot during a recording, playback cue, or unattended critical output period.

#4.7 Reboot and shutdown

These are host-level actions. They interrupt ASIO, plugin DSP, playback, recording, state synchronization, and editors. Stop recording, save state, mute the system, and obtain operational clearance before use.

#5. ASIO configuration

#5.1 Device discovery

Click Refresh, then select the intended ASIO driver. Some drivers allow exclusive access only. Close DAWs, measurement tools, control panels, or other ASIO hosts that may own the device.

A driver can remain listed while the hardware is disconnected. Treat successful ASIO start and correct channel enumeration as the real verification.

#5.2 Sample rate

Choose a driver-supported rate consistent with the production chain. Sample rate affects:

• converter/driver configuration;
• ASIO block duration;
• plugin CPU and internal modes;
• plugin state behavior in some products;
• playback resampling/decoding;
• recording file rate;
• PDC and transport-time conversion.

Rehearse the exact production rate. Do not assume a plugin preset prepared at another rate is acoustically or computationally equivalent.

#5.3 Buffer size

Block duration is approximately:

buffer frames / sample rate

Example at 48 kHz:

This is not total round-trip latency. Driver input/output buffers, converters, plugin latency, PDC, isolated transport, and external processing add to it.

Select the smallest buffer that remains stable under the heaviest validated workload, not the smallest value that starts an empty graph.

#5.4 MMCSS

MMCSS (ASIO/engine) is enabled by default. It integrates the relevant work with Windows multimedia scheduling. Leave it enabled for normal production unless a particular driver/system has been measured under both settings.

#5.5 ASIO start and stop

ASIO Start commits the selected device/rate/buffer and activates the audio path. ASIO Stop removes the live device path.

Stop ASIO before:

• changing device/rate/buffer;
• playback cache cleaning;
• maintenance that affects interface availability;
• planned Waves Prewarm;
• driver/control-panel reconfiguration;
• host shutdown/reboot.

#5.6 Auto-start ASIO

Auto-start is enabled by default as a next-Core-start policy. It succeeds only when a valid remembered device, sample rate, and buffer can be resolved. If the interface is absent, renamed, or exposes different capabilities, manual intervention can be required.

#5.7 Latency accounting

The UI reports driver-side latency, but the complete path is:

converter/driver input
+ ASIO input buffering
+ rack/plugin processing
+ per-rack/global PDC
+ isolation transport blocks
+ ASIO output buffering
+ converter output

For time-critical monitoring, measure analog-in to analog-out latency under the final graph.

#6. Plugin catalog and scanning

#6.1 Supported plugin formats

Current plugin formats:

• VST3
• CLAP

Other plugin formats are not selection targets.

#6.2 Scan roots

The scanner uses configured server-side folders and common default roots. LiveSoundRack also creates sibling local drop folders:

<Server Core folder>\VST3\
<Server Core folder>\CLAP\

The CLAP environment path and common installed locations can also contribute roots. The browser folder dialog operates on the server filesystem.

#6.3 Scan procedure

1. Install/license server plugins.
2. Add required roots.
3. Scan during maintenance.
4. Review catalog counts and status.
5. Exclude redundant, unsafe, or unused components.
6. Normalize displayed vendor/category metadata where useful.
7. Instantiate and state-test every production plugin.

A successful catalog entry is not proof of stable realtime operation. Test load, GUI, parameter automation, state save/restore, bypass, sample-rate changes, and isolation behavior.

#6.4 Exclude/Include

Exclusion is a catalog visibility flag. It does not uninstall the binary. Existing console/preset dependencies still require the component to be available.

Use exclusion to remove duplicate shells, unsupported layouts, demo components, or unsafe plugins from operator selection menus.

#6.5 Edit metadata

Vendor/category edits are organizational metadata. They do not rewrite the plugin binary or change class identity. This is useful for consistent menu organization when vendor metadata is incomplete.

#6.6 Scan failure considerations

Potential causes include:

• invalid/unsupported binary;
• vendor license prompt or service failure;
• architecture mismatch;
• plugin crash/hang;
• missing runtime dependency;
• inaccessible path;
• corrupted package;
• duplicate/ambiguous component identity.

Resolve the plugin independently before trusting it in a production console.

#7. Waves Prewarm

#7.1 Purpose and conditions

Waves Prewarm initializes an eligible Waves VST3 before normal use to improve first-use stability after boot.

Required operating conditions:

• plugin scan has found an eligible Waves VST3;
• Auto-initialize Waves (Server) is enabled;
• Plugin Process Isolation is Off;
• audio is stopped;
• the offered Waves Prewarm action is accepted.

#7.2 Operator sequence

1. Stop ASIO.
2. Set isolation to Off.
3. Enable Auto-initialize Waves.
4. Scan the intended roots.
5. Choose Yes in the confirmation.
6. Keep the LiveSoundRack Tray app open.
7. The LiveSoundRack server restarts automatically once.
8. Confirm the Server returns and the Waves plugin instantiates normally.

ASIO is unavailable briefly while the restart completes. Do not close the LiveSoundRack Tray app during this sequence.

#7.3 Limitations

Prewarm does not guarantee that every Waves product, license, preset, or future state will load. It is not a replacement for vendor license preparation and full production-plugin rehearsal.

#8. Rack graph and signal flow

#8.1 Signal path

The operational path is:

ASIO input / Playback virtual input / Test Signal
  → input routing
  → rack Input Gain
  → Automixer
  → slot chain
     ↳ sidechain source/timing paths
  → rack bypass/output gain/mute
  → per-rack and global latency alignment
  → output routing
  → ASIO output

Playback never reaches a physical output without a rack route. Test signals likewise require explicit routing.

#RACK toolbar indicators

• ERROR: n is the sum of ASIO OverLoads, DSP Overruns, and Dropout Signals. Click it to inspect the individual counters or use RESET.
• CPU n% reports Server CPU use and opens CPU Monitor when clicked.
• RAM n% reports physical memory use for the whole Server PC. Orange/red decoration reports the separate system memory-pressure state. A plugin add requires shared confirmation whenever the latest valid commit measurement is 80% or higher, which can occur on the first high sample before the orange two-sample Warning marker appears.
• DFB Response appears only for the supported De-Feedback 1.1.4 catalog identity/version and lets you choose the feedback response speed.
• ▲ / ▼ collapses or expands the Rack area.
• Remove Last (n) removes the last Rack; n identifies the Rack that will be removed.
• ASIO Start and ASIO Stop are available from SETUP or the LiveSoundRack Tray menu, not from the RACK toolbar.

The three ERROR counters are runtime diagnostics owned by ServerCore:

These counters are diagnostic signals, not an exact count of audible clicks. RESET changes the published baselines and restarts the partial diagnostic windows without stopping ASIO. A new ASIO Start also begins a new counter session. The values are runtime-only and are not stored in Console files or settings.

DFB Response adjusts the feedback response speed when supported De-Feedback 1.1.4 is installed.

#8.2 Rack identity and display order

Racks have stable server identities and a separate display order. Dragging a rack changes its visible order without treating the display index as the durable identity. Clients that act on stale identities can be rejected and must refresh.

For operators, the practical rule is simple: after another operator reorders or replaces racks, allow the UI to synchronize before issuing additional structural commands.

#8.3 Rack count

At least one rack remains. The server accepts a high rack-count ceiling, but capacity is bounded in practice by:

• plugin DSP cost;
• ASIO buffer and sample rate;
• rack meter/control traffic;
• memory and state size;
• isolation process count;
• PDC delay storage;
• UI manageability;
• routing topology.

Size for measured worst-case operation rather than the protocol ceiling.

#8.4 Mono and Stereo width

• Mono uses the left signal path; right input/output controls are inactive.
• Stereo uses left and right paths.

Rack preset loading requires matching width. Width choice affects plugin bus compatibility and sidechain topology; define it before final plugin construction.

#8.5 Input routing invariants

• Each rack input destination has at most one selected source.
• A source can feed multiple rack inputs.
• Physical ASIO inputs, Playback L/R, and test signals are valid source families.

This permits parallel processing of one source while preventing ambiguous multiple-source assignment to a single destination.

#8.6 Output routing invariants

• Each rack output destination has at most one physical ASIO destination.
• Each physical ASIO output destination has at most one rack-output owner.

LiveSoundRack therefore does not implicitly sum multiple racks into one hardware output destination. Build any desired combination inside the intended rack/signal design rather than assigning two rack outputs to the same ASIO channel.

#8.7 Test signals

Current virtual test sources:

• Pink Noise
• 300 Hz
• 500 Hz
• 1 kHz
• 2 kHz
• 4 kHz

They are continuous whenever routed and ASIO is running. Use a muted rack, low Output Gain, verified destination, and controlled downstream system. Remove test routes after commissioning.

#8.8 Gain controls

Input and Output Gain range:

-60 dB to +24 dB, 0.5 dB steps

Input Gain is a digital trim after source routing. Output Gain is after rack processing. Maintain headroom through the plugin chain; do not rely on output attenuation to conceal internal clipping.

#8.9 Meters

Input and output meters are operational views of the current rack. Meter transport is not the production audio path. A temporarily stale client meter does not prove that server audio has stopped; confirm server/ASIO status and physical monitoring.

#8.10 Automixer

Automixer operates at the rack input stage. Use it where automatic gain sharing is appropriate, typically spoken-microphone groups. Evaluate:

• number of open microphones;
• ambience modulation;
• speech handoff;
• feedback margin;
• source noise;
• interaction with downstream compression/gating.

Do not enable it on program/playback/effects paths without a defined reason.

#8.11 Rack bypass, mute, and PDC

• Rack bypass changes the processing behavior of the rack.
• Output mute silences its output contribution.
• Per-rack PDC controls latency compensation participation/timing.
• Global PDC aligns rack outputs to the largest active latency.

Bypass/mute/routing changes can be smoothed by Audio Transition Time when isolation is Off.

#9. Plugin slots and graph changes

#9.1 Slot capacity and ordering

Each rack supports up to 32 plugin slots. The ordered slot layout determines processing order.

#9.2 Insert/replace/remove

Click an empty slot and select a plugin by format/vendor/category. Replacing/removing a plugin changes the graph and its state ownership. Use safe transition settings and avoid unplanned structural edits during critical audio.

#9.3 Slot context actions

App and Web use the same common action area for empty and loaded slots. An empty slot still shows the action area plus the VST3/CLAP vendor/category selection list. Its action state is:

Healthy loaded slots provide:

• Empty Slot
• Bypass Plugin
• Open Editor(Original)
• Open Editor(Generic)
• Copy Plugin
• Paste Plugin
• Save Plugin Preset
• Save Plugin Preset As
• Load Plugin Preset
• Reload Isolated Plugin Host, when active

Crashed isolated slots provide:

• Empty Slot
• Bypass Plugin
• Reload Plugin
• Acknowledge Crash

#9.4 Drag and drop

Plugin instances can be reordered or moved between slots/racks. The system preserves stable slot-instance identity semantics for the accepted operation and publishes the resulting graph.

Operationally:

• use LOCK after commissioning;
• avoid dragging from a stale client view;
• verify sidechain/PDC behavior after a cross-rack move;
• save after final placement.

#9.5 Plugin bypass

Plugin bypass retains the plugin in the slot. Some plugins have vendor-specific bypass/state behavior; verify whether tails, latency, and internal metering behave as required. Audio Transition can smooth the path when isolation is Off.

#9.6 Copy/Paste Plugin

Copy captures the selected plugin's identity/state for paste. Paste performs preflight and can request confirmation before target replacement. The server must have the copied plugin available, and state restoration remains subject to plugin compatibility.

#10. Plugin editors

#10.1 Generic Editor

The Generic Editor is a server-parameter view rendered in the Web UI. It:

• requires no plugin binary on the client;
• displays editable parameters published for the slot;
• sends authoritative parameter changes to ServerCore;
• does not reproduce manufacturer layout, custom graphics, meters, RTA, or non-parameter UI behavior.

For isolated plugins, parameter descriptors are cached immutably by PluginHost and exposed through a bounded on-demand shared snapshot. ServerCore validates session and plugin identity before using the metadata. Descriptor acquisition is a non-realtime control operation; the audio request/response path is unchanged. This keeps parameter names and ranges available in isolation mode without changing the audio transport.

#10.2 Original Editor — local

Original Editor uses the manufacturer's GUI. On the server/same Windows computer, the editor flow can load the installed component and synchronize with the server slot.

#10.3 Original Editor — remote Windows Client

A separate client computer needs a matching, locally loadable VST3/CLAP component. Use the exact same version/build as the server whenever possible; identity, bus layout, dependencies, licensing, and state compatibility remain vendor-controlled.

LiveSoundRack.Client.exe creates sibling VST3 and CLAP folders when possible. EditorHost resolves the component in this order:

1. Use the absolute server plugin path when that identical path exists on the client.
2. Search the existing local editor catalog for matching format and stable identity.
3. Run the default local scanner when no catalog match exists.
4. Include the Client sibling drop folders and standard Windows VST3/CLAP installation locations.
5. For VST3, compare Class ID case-insensitively; for CLAP, compare plugin ID exactly.
6. Accept only an existing container with matching format and identity.

Prefer the manufacturer's installer. For standalone distribution, copy the complete .vst3 bundle/container or CLAP package into the appropriate Client sibling folder. A display-name match is not sufficient. Windows Client starts LiveSoundRack.Client.EditorHost.exe only after the selected server target is resolved by stable rack, slot, slot-instance, and plugin identity.

#10.4 Original Editor — browser fallback

Chrome cannot launch an Original Editor directly. Select Open Editor (Original) in Chrome to see the Client guidance, then open LiveSoundRack.Client.exe and retry from the RACK screen.

The plugin's Original Editor is available in the LiveSoundRack Client app.

Please open LiveSoundRack.Client.exe and try again from the RACK screen.

If the Client Original Editor does not open, check:

• local plugin availability/version;
• firewall reachability;
• current server/rack/slot identity.

#10.5 Shadow-plugin authority

The remote/local EditorHost plugin instance is a shadow for GUI/control. It is not the server's production DSP return path. Parameter changes synchronize to Server Core; the server plugin continues to process show audio.

This distinction matters when a vendor GUI displays internal state that is not exposed as parameters. Validate that the required controls synchronize as expected.

#10.6 Remote Live Audio

Live Audio is an optional monitor-only preview for a remote Original Editor. It captures the selected server slot's post-PDC, pre-plugin main input and optional sidechain signal so vendor meters/RTA/analyzers can react. The authoritative server plugin and production output path remain unchanged.

Transport contract:

The ServerCore non-realtime owner drains native and isolation capture rings using existing wake/socket events. Live Audio Off waits indefinitely. If backlog remains, the owner drains immediately, but missed cadence is not replayed from the past.

EditorHost keeps one latest complete window. Receive bursts are coalesced, intermediate windows are overwritten if shadow DSP is slow, and no synthetic silence blocks are processed when a new window is absent. The design is deliberately best-effort/latest-only: UDP loss, jitter, or slow shadow processing causes visual discontinuity rather than queue growth or delayed catch-up.

The shadow plugin's output is discarded and never returned to production audio. This stream is not post-plugin confidence monitoring, is not persisted with the show, and cannot animate a visualization the plugin does not implement.

#11. Sidechain

#11.1 Availability

Sidechain controls appear in the Original Editor top bar only when the plugin exposes a compatible external sidechain input.

#11.2 Source selection

Select an eligible external rack source from the server-provided list. The source can represent the available raw or processed path according to the route offered.

#11.3 Timing

Sidechain timing interacts with source-rack latency and destination plugin latency. Keep per-rack/global PDC enabled when alignment is required, then verify with material and measurement appropriate to the processor.

#11.4 Graph constraints

• A source rack cannot be removed while referenced by an active sidechain.
• Copy/paste/preset load checks route validity.
• Invalid references are cleared or trigger confirmation rather than binding to a different rack by display position.
• A remote editor can receive sidechain Live Audio preview when enabled, but the authoritative route remains on the server.

#12. Plugin Delay Compensation

#12.1 Per-rack PDC

Per-rack PDC participates in timing alignment for the rack processing path and related sidechain timing.

#12.2 Global PDC

Global PDC determines the highest active rack latency and delays lower-latency racks to align outputs.

#12.3 Tradeoff

PDC improves phase/time alignment but increases latency for paths that would otherwise be faster. It also requires delay storage and depends on accurate plugin latency reporting.

Verify:

• parallel rack phase relationship;
• sidechain detector timing;
• monitor latency tolerance;
• behavior when a high-latency plugin is bypassed/replaced;
• plugin latency reporting after sample-rate or quality-mode changes.

A plugin that reports latency incorrectly cannot be perfectly corrected by the host.

#13. Rack presets, plugin presets, clipboard, and reset

#13.1 Plugin presets

A plugin preset stores one plugin's identity-associated state. Storage includes metadata and binary state under the server's LiveSoundRackData\Plugins hierarchy.

Load requirements:

• matching server plugin available;
• compatible plugin state version;
• valid target slot/replacement;
• successful non-realtime state restore.

Use Save As for intentional named snapshots and verify recall before production.

#13.2 Rack presets

A rack preset stores:

• preset and rack name;
• Mono/Stereo width;
• input/output gains;
• rack enabled/bypass state;
• output mute;
• Automixer;
• per-rack PDC;
• slot layout;
• plugin identities and versions;
• plugin bypass states;
• parameter overrides;
• sidechain definitions;
• binary plugin states.

A rack preset does not replace the target rack's physical input/output route assignment. Loading requires matching rack width. Existing target plugins require confirmation. Missing plugins or version mismatch reject the load. Sidechain definitions that are not valid in the current rack graph are cleared.

#13.3 Copy/Paste Rack

Rack clipboard captures the rack processing configuration and plugin states. Paste preserves the target rack's physical routing while replacing processing content. Preflight checks plugin availability and sidechain compatibility.

#13.4 Reset Rack

Reset preserves:

• rack stable identity;
• display order;
• width;
• input routes;
• output routes;
• slot-layout positions as empty rows.

It clears other rack settings and plugins. Use it only after confirming that retained routes are still safe with the reset gain/mute state.

#14. Console persistence and switching

#14.1 Console scope

A console is the complete show-level rack/routing/plugin state required for recall, including:

• rack count, identity/order, width, names and colors;
• physical/virtual routing;
• input/output gains, mute, bypass, Automixer and PDC;
• slot layout and plugin identity;
• parameter overrides and binary plugin state;
• sidechain routes;
• rack/plugin preset association/dirty metadata required by the UI.

Playback playlists/configuration and Record profiles have their own persistence areas and are not substitutes for console state.

#14.2 Console controls

The Console File button has two actions:

• Left-click opens the recent Console File list. Selecting an item changes to that Console File.
• Right-click opens Load, Save, and Save As.

The X beside a recent item deletes the corresponding Console File after confirmation.

#14.3 Autosave

Autosave intervals:

• 10 seconds
• 30 seconds
• 60 seconds

Default selection is 30 seconds. Autosave persists accepted current state; it is not a version-control system. Preserve an offline baseline before risky edits.

#14.4 Dirty state

The dirty indicator compares the current accepted Server state with the last completed save. If another change is accepted while saving, the Console stays dirty until it is saved again.

For operators, save again after the last accepted change and observe that the dirty indicator clears.

#14.5 Instant, Fade, and Crossfade

#Instant

Switches without transition processing. Lowest temporary graph overhead, highest likelihood of audible discontinuity from incompatible state/topology changes.

#Fade

Fades output down, commits the target console, then fades up. Available durations:

1 ms, 5 ms, 10 ms, 100 ms, 250 ms, 500 ms,
1 s, 2 s, 3 s, 5 s, 10 s

#Crossfade

Runs old and target graphs concurrently and crossfades for:

1 s, 2 s, 3 s, 5 s, 10 s

Crossfade is available only with Plugin Process Isolation Off. It can approach roughly double graph DSP/memory during overlap. Measure the heaviest old/new pair at the intended buffer and sample rate.

#14.6 Console load preconditions

A console can fail or be unsafe to load when:

• required plugin is absent;
• plugin version/state is incompatible;
• ASIO topology differs from the intended route labels/counts;
• CPU is insufficient for Crossfade;
• external license services are unavailable;
• a recording or other operation makes the chosen action operationally inappropriate.

Keep a minimal recovery console that uses verified low-risk components.

#15. OPTION — audio and plugin stability

#15.1 Audio-Safe Plugin State Saving

When enabled, plugin-state capture uses a shadow/non-realtime-safe workflow intended to reduce audio interruptions. The tradeoff is additional CPU/memory use.

Test state saving under full graph load. A plugin can still reject, hang, or return invalid state; the option does not override vendor behavior.

#15.2 Audio Transition Time

Available values:

• disabled/none;
• 1 ASIO block;
• 5 ASIO blocks;
• 10 ASIO blocks;
• 10 ms;
• 100 ms;
• 1 s.

It smooths abrupt changes including plugin/rack bypass, mute, routing, plugin replacement, and engine transitions. Block-relative values scale with the current ASIO buffer/rate.

Audio Transition is disabled with active Plugin Process Isolation because the isolated transport path uses a different transition constraint.

#15.3 Plugin Process Isolation modes

#Off

All plugin DSP is in ServerCore. Benefits: lowest process count, memory overhead, inter-process transport, and nominal latency. Risk: a plugin crash/hang can affect Core.

#Group by Plugin

Instances of one plugin identity share a logical grouping. Fault scope follows the plugin family.

#Group by Rack

Plugins in one rack share a logical grouping. Fault scope follows rack organization.

#Isolate Each Slot

Each slot receives an independent grouping. This is the strongest fault separation and the highest process/RAM/handle/control overhead.

Current physical PluginHost audio transport exposes eight main lanes. Logical shared groups larger than one physical host capacity are partitioned through the topology/sharding path. Exact hosts are prepared with bounded parallelism (maximum eight concurrent launch/preparation operations), and retired host shutdown is also parallelized outside the realtime path.

#15.4 Isolation transport latency

Configured from 0 to 10 ASIO blocks. The first-run value is 2 blocks. Approximate added time is:

blocks × buffer frames / sample rate

A 2-block setting at 48 kHz/128 samples is about 5.33 ms of transport time, in addition to other latency.

Use more blocks when isolated hosts need scheduling margin. Zero is the most aggressive and can crackle/drop when the process cannot return data in time.

#15.5 Isolation compatibility and transition behavior

While isolation is active:

• Audio Transition Time controls are unavailable.
• Console Crossfade is unavailable.
• Use Instant or Fade console change.
• Waves Prewarm cannot run.
• Shared grouping means one host crash can affect all slots assigned to that physical host/group.

Isolated Console Fade does not prime a duplicate shadow audio graph. ServerCore prepares the required target backends outside the callback, fades out, performs a silent block-boundary swap, and fades in. Isolated Crossfade remains intentionally converted/blocked rather than running two isolated graphs concurrently. These constraints protect realtime scheduling and process-transport ownership.

#15.6 Crash recovery

A crashed isolated slot exposes Empty, Bypass, Reload Plugin, and Acknowledge Crash.

Suggested recovery order during a show:

1. Bypass the crashed plugin if the dry/surviving path is acceptable.
2. Confirm the affected group scope.
3. Reload during a safe segment.
4. Empty the slot if repeated failure threatens stability.
5. Acknowledge only after the operator understands the resulting state.

Reloading can interrupt every slot sharing the same host group.

#16. Playback

#16.1 Architecture and routing

Playback decodes on background workers and fills a server-side source consumed by the realtime graph. Its output is the virtual stereo pair:

Playback L
Playback R

Route these to a Stereo rack, process as required, and assign that rack to ASIO outputs. Playback time can advance even if no route reaches hardware.

#16.2 Server-side file selection

The ADD dialog browses the server filesystem. Remote workstation paths are not local to the server. Store production media on a server-accessible, stable volume.

Backend-accepted extensions:

.wav  .wave  .mp3  .m4a  .aac  .flac  .wma

Decoding uses Windows Media Foundation. Codec/container availability and file validity still determine success.

#16.3 Transport

Controls:

• Stop
• Pause
• Play
• Previous
• Next
• Add
• seek through waveform/position

Transport state is server-authoritative and shared by clients.

#16.4 Play modes

• stop after this track;
• stop after this list;
• repeat this track;
• repeat this list;
• shuffle this list;
• shuffle all lists.

Verify end behavior and selection order for every cue-critical playlist. Shuffle is unsuitable for deterministic cue order unless explicitly required.

#16.5 Playlist tabs

Multiple persistent playlist tabs can be created, renamed, removed, reordered, and selected. Each playlist has a stable identity separate from its visible order/name, so accepted reordering does not redefine the underlying playlist identity.

Rows can be moved to top, up, down, bottom, or removed. Removing a row does not delete the media file.

#16.6 Playback gain

Volume range:

-60.0 dB to +24.0 dB

Gain Transition choices:

0, 100 ms, 500 ms, 1 s, 2 s, 3 s, 5 s, 10 s

Use gain transition to avoid abrupt AutoGain/manual volume changes.

#16.7 AutoGain

AutoGain follows ITU-R BS.1770 / EBU R128-style analysis and targets -23 LUFS. Analysis is asynchronous.

Constraints:

• at most the first 300 seconds are analyzed;
• pending/failed analysis does not prevent manual operation;
• loudness normalization is not a replacement for artistic cue balancing;
• short effects, long-form program, and highly dynamic material require review.

#16.8 Safety Limiter

Ceilings:

none, 0, -0.5, -1.0, -1.5, -2.0, -2.5, -3.0 dBFS

The default selected ceiling is -1.5 dBFS.

The limiter addresses decoded/inter-sample/format-conversion overshoot in the playback source. It is upstream of rack plugins and rack gain; downstream processing can still clip.

#16.9 Fades

Independent controls:

• Play in;
• Pause out;
• Stop out;
• Change in;
• Change out;
• Change cross.

Values:

0, 1, 2, 3, 5, 10 seconds

Track-change behavior combines the selected in/out/cross settings. Rehearse cue transitions with the actual media.

#16.10 Waveform and seek

Waveform analysis creates 1024 min/max bins. It is unavailable for tracks longer than 600 seconds. Playback remains available without waveform data.

Waveform data is cached. Clicking/seeking changes the server playback position; every connected client receives the resulting state.

#16.11 Analysis cache

Cache location:

LiveSoundRackData\Playback\AnalysisCache\

Clean Cache removes orphan analysis files and is enabled only while ASIO is stopped. Do not manually manipulate active transaction/cache files while Server Core is running.

#16.12 Decode and storage constraints

Playback uses background decode/prebuffering, but slow storage, unavailable codecs, damaged media, or heavy system contention can starve the source. Copy all production files locally, validate every file, and avoid removable/network media unless its failure behavior has been accepted.

#17. Recording

#17.1 Tap points

#Input taps

• physical ASIO input before rack processing;
• Playback L/R virtual input at its generated source.

#Output taps

• final ASIO output channel after rack processing/routing and before device submission.

This is not a free-form per-rack stem recorder. To record a specific rack stem, route/design the ASIO output topology accordingly or use an external capture plan.

#17.2 Channel table

Each row contains:

• enable state;
• channel number;
• source or ASIO name;
• Record Name.

Enabled names must pass the common filename policy. Channel/profile controls are disabled while recording.

#17.3 Start preconditions

• ASIO running;
• at least one enabled channel;
• valid Record Names;
• current committed ASIO topology;
• writable record path;
• adequate free space and throughput.

#17.4 File format

Each selected channel produces a separate:

• mono WAV;
• 32-bit IEEE floating point;
• active ASIO sample rate.

A file is split before the WAV data section reaches 2 GiB. Numbered parts continue the channel:

ch_01_Lead_Vocal_001.wav
ch_01_Lead_Vocal_002.wav

#17.5 Session path

LiveSoundRackData\Record\Sessions\<ProfileName_YYYYMMDDHHMMSS>\INPUT\
LiveSoundRackData\Record\Sessions\<ProfileName_YYYYMMDDHHMMSS>\OUTPUT\

#17.6 Realtime-to-disk queue

The callback enqueues record blocks without waiting for disk I/O. Queue capacity is 256 ASIO blocks. If the writer cannot keep up, blocks can be dropped rather than blocking realtime audio.

At 48 kHz/128 samples, 256 blocks represent about 0.68 seconds of block depth; actual byte throughput depends on channel count. Do not treat the queue as protection against sustained slow storage.

Commission with:

• maximum channel count;
• full planned duration;
• simultaneous playback;
• expected antivirus/indexer policy;
• the exact storage volume and free-space condition.

#17.7 Record profiles

Profile actions:

• Load
• Save
• Save As

Profiles store selected channels and Record Names. They are tied to the committed ASIO topology.

Compatibility rules include:

• a committed ASIO device is required;
• physical input/output counts must match;
• a different device identity can reject the profile;
• changed channel display names with the same indexed layout can be retained with warning.

Reload and verify profiles after driver, firmware, interface, or routing changes.

#17.8 Stop/finalization

Stop recording before restart/shutdown. Stop allows queued blocks to flush and WAV headers to finalize. A forced process termination can leave the newest file incomplete.

#18. SERVER tab and recovery

#18.1 Status

The selected server view reports:

• Server tray supervisor;
• Server Core;
• Server Web;
• ASIO Audio;
• Record;
• Playback.

Unknown indicates unavailable/insufficient confirmation, not necessarily a failed component.

#18.2 Normal Core restart

Use normal restart first. It requests a supervised Core restart and interrupts:

• ASIO audio;
• playback;
• active recording;
• client state streams;
• Original Editor sessions;
• isolated plugin hosts.

Stop recording and save state before use.

#18.3 Force restart

Force restart is for an unresponsive Core. It has greater risk of incomplete state/file finalization. It should be an assigned operator action, not a general troubleshooting first step.

#18.4 Client disconnect/reconnect

Server audio continues without a client. On reconnect, the client obtains authoritative state. Do not act on controls that still show stale disconnected values; wait for server availability and synchronized state.

#18.5 Isolated plugin failure

Isolation contains failure according to grouping. Determine whether the affected host contains:

• one slot;
• a rack;
• all instances of a plugin;

Bypass or reload with knowledge of the group scope. A reload can affect healthy slots sharing the host.

#19. License and demo

#19.1 Demo

The demo runs for 30 minutes from Server Core start. Remaining time appears in tray/ABOUT.

After expiry, audio output may be intermittently muted for 10 seconds. Restarting Server Core starts a new demo period.

Do not rely on restart-based demo use for production continuity.

#19.2 Activation

ABOUT provides Activate/Deactivate. Activation uses an email and access key and may require Internet access. Confirm licensed state after reboot and before disconnecting any temporary commissioning Internet path.

#19.3 License operational planning

• Follow vendor rules before hardware/OS migration.
• Keep access credentials secure.
• Test offline operation if the production network has no Internet.
• Confirm third-party plugin licenses separately; LiveSoundRack activation does not license plugins.

#20. Runtime data and persistence

#20.1 Root layout

LiveSoundRack creates a working layout beside Server Core:

<Server Core folder>\
  LiveSoundRackData\
  VST3\
  CLAP\

VST3 and CLAP are local plugin drop/scan roots. Main application data remains in LiveSoundRackData.

#20.2 LiveSoundRackData contents

LiveSoundRackData\
  PluginFolder.json
  VST3.json
  CLAP.json
  EDITED_PLUGIN.json
  Consoles\
  States\
  Backups\
    Consoles\
    States\
  Temp\
  Record\
    Sessions\
  Playback\
    AnalysisCache\
  Plugins\
  Racks\

#Catalog files

• PluginFolder.json — configured scan roots.
• VST3.json — VST3 catalog.
• CLAP.json — CLAP catalog.
• EDITED_PLUGIN.json — operator vendor/category display overrides.

#Console/state

• Consoles\ — console JSON.
• States\ — console-associated binary plugin state.
• Backups\Consoles\ — timestamped console backups.
• Backups\States\ — state backup area.

#Temp

Temporary atomic-write, clipboard, plugin-state and Waves marker data. Do not clean it manually while Core is running.

#Record

Profiles and Sessions\<timestamp> WAV output.

#Playback

Configuration, playlist JSON, transaction data and AnalysisCache metadata/waveforms.

#Plugins and Racks

Named plugin and rack preset directories containing metadata and binary state.

#20.3 Registry and Startup

Host settings/license/protocol data uses the current user's Windows environment, including HKCU\Software\LiveSoundRack. Start with Windows creates:

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\LiveSoundRack.Server.lnk

A backup of LiveSoundRackData does not necessarily include every registry setting, third-party license, or driver preference.

#20.4 Write permissions

The server directory must permit directory/file creation and atomic replacement. Protected installation locations can require adjusted ACLs or elevation, which is undesirable for routine live operation. Use a controlled writable path.

#20.5 Backup procedure

With Server stopped:

1. Copy complete LiveSoundRackData.
2. Copy sibling VST3/CLAP drop folders if used.
3. Preserve exact plugin installers/builds.
4. Preserve vendor license assets through supported tools.
5. Record ASIO driver/interface firmware and topology.
6. Record Windows, network, firewall, and startup settings.

#20.6 Restore procedure

1. Restore LiveSoundRack and data to a writable path.
2. Install the same ASIO driver/interface configuration.
3. Install/license exact plugin versions.
4. Restore local drop folders.
5. Start Server with downstream muted.
6. Scan/confirm catalog.
7. Load a recovery console.
8. Verify plugin state and sidechains.
9. Verify physical routes by channel identity/name.
10. Test playback/record profiles.
11. Save a fresh baseline only after validation.

Plugin state compatibility is controlled by the plugin vendor; a byte-for-byte state file is not a guarantee across versions or machines.

#21. Naming policy

Managed names apply to consoles, rack presets, plugin presets, record profiles, playback playlists/tabs, and Record Names.

#21.1 Allowed characters

• Unicode letters;
• decimal digits;
• ordinary spaces;
• underscore _;
• hyphen -;
• period ..

Names are normalized to Unicode NFC.

#21.2 Rejections

• empty/whitespace-only;
• more than 128 characters;
• unsupported character;
• leading/trailing whitespace;
• . or ..;
• trailing period;
• Windows reserved device name: CON, PRN, AUX, NUL, COM1–COM9, LPT1–LPT9;
• managed prefix such as Console. entered by the user;
• managed file extension such as .json or .wav entered by the user.

Use names that remain unambiguous in plain directory listings and backup systems.

#21.3 Client rendering and authoritative admission

App and Web Rack screens use a centralized render coordinator. The client diffs an immutable admitted UI snapshot by stable rack/slot identity and patches only affected racks, cells, controls, and layout when safe. First connection, session replacement, recovery, dependency corruption, or an invalid layout triggers a full rebuild fallback.

This is a presentation optimization only. The coordinator does not own Rack state and cannot synthesize a successful mutation. All structure still comes from the validated five-domain checkpoint/Delta store, and one reconciliation gate prevents redundant competing repaints.

#22. Performance engineering

#22.1 Primary load variables

• sample rate;
• ASIO buffer;
• rack count;
• plugin count and algorithm;
• oversampling/linear-phase/convolution settings;
• PDC delay and sidechain complexity;
• isolation mode/process count;
• isolation transport blocks;
• console Crossfade;
• playback decode/analysis;
• record channel count/storage;
• local client/GUI load;
• network/remote editor activity;
• Windows/driver/DPC behavior.

#22.2 CPU headroom

Measure peak and sustained load under realistic dynamics. Some plugins are program-dependent and spike only with specific audio or UI activity. Test:

• all meters/editor windows open;
• preset/state save;
• bypass and routing transitions;
• console switch;
• isolated host reload;
• playback track change;
• recording start/stop;
• high-density transients.

#22.3 Thermal and power behavior

A brief stress test may pass before the CPU reaches thermal equilibrium. Run long rehearsals with production cooling, Windows power policy, laptop AC state, and any turbo/current limits. If the LiveSound.App Performance Power Plan is enabled, include its power usage, fan noise, cooling capacity, and laptop AC state in the long-duration validation.

#22.4 Storage

Recording throughput for 32-bit float mono is approximately:

sample rate × 4 bytes × selected channel count

At 48 kHz, each channel is about 192 kB/s before filesystem overhead; 64 channels are roughly 12.3 MB/s. Sustained throughput is normally manageable for modern local storage, but latency spikes from antivirus, paging, thermal throttling, or external media can exhaust the finite queue.

Playback media and recording target should not compete on an unreliable slow device.

#22.5 Network

Remote Live Audio is an optional visual preview for compatible meters, RTA, and analyzer displays. Network conditions can affect the preview without affecting server audio.

Control reliability does not imply Live Audio quality, and Live Audio quality does not determine server DSP stability.

#23. Operational constraints and failure matrix

#24. Commissioning acceptance tests

#24.1 Baseline

• Server tray starts Core and Web.
• Direct Web URL and Windows Client connect.
• Server components report expected status.

#24.2 ASIO

• Correct device/rate/buffer starts repeatedly.
• Auto-start survives reboot.
• Full-load xrun/dropout test passes.
• Measured latency is acceptable.
• Device channel names/counts match documentation.

#24.3 Plugin catalog

• All required VST3/CLAP components scan.
• Unused components excluded.
• Every production plugin instantiates at production rate/buffer.
• State save/reload and console restore pass.
• Vendor licensing works without commissioning Internet if required.
• Waves Prewarm completes when applicable.

#24.4 Rack/routing

• Every physical input maps to intended racks.
• Duplicate-input fan-out is intentional.
• Every physical output has one intended owner.
• Test signals are removed.
• Mono/Stereo width and plugin bus layouts are correct.
• Gains, mutes, bypass, Automixer and meters are verified.
• Rack LOCK enabled after final build.

#24.5 PDC/sidechain

• Plugin-reported rack latency is plausible.
• Parallel paths align as required.
• Sidechain source/path is correct.
• Sidechain source-rack removal protection verified.
• Preset/copy behavior with sidechain dependencies is understood.

#24.6 Isolation/recovery

• Selected group mode/process count is acceptable.
• Transport latency has no underrun under full load.
• Expected group failure/reload behavior tested.
• Audio Transition/Crossfade restrictions accepted.

#24.7 Consoles/presets

• Baseline and recovery consoles load from clean startup.
• Autosave policy verified.
• Fade/Crossfade worst-case measured.
• Plugin and rack presets restore exact intended state.
• Backup restore tested on representative copy when possible.

#24.8 Playback

• Playback L/R routed.
• Every production media file decodes.
• Cue order/play mode/fades verified.
• AutoGain values reviewed.
• Limiter and downstream headroom verified.
• Waveform/seek expectations accepted for long files.

#24.9 Record

• Profile matches topology.
• Maximum selected channels record for full rehearsal duration.
• Files open correctly in an independent application.
• Split-file behavior and naming accepted.
• Storage headroom and dropped-block status verified.

#24.10 Remote editors

• Generic Editor parameter control passes.
• Original Editor exact plugin version installed or identity-matched through the Client VST3/CLAP/standard-location scanner.
• Chrome shows the Client guidance when Open Editor (Original) is selected.
• Parameters synchronize both directions as expected.
• Sidechain controls pass.
• Live Audio preview is tested or intentionally disabled.

#24.11 Recovery

• Client disconnect/reconnect.
• Web gateway reconnect.
• Normal Core restart.
• Force restart in controlled maintenance.
• Windows reboot/startup restoration.
• Interface power-cycle recovery.

#25. Show operating procedure

#25.1 Pre-show

1. Boot early enough for licensing and prewarm.
2. Verify licensed state and demo absence.
3. Verify direct server address and client connectivity.
4. Confirm ASIO device/rate/buffer/MMCSS.
5. Load production console.
6. Confirm dirty state and Autosave policy.
7. Line-check input routes and physical output ownership.
8. Test critical sidechains/PDC.
9. Confirm CPU, RAM pressure, DFB Response, and isolation host status.
10. Route/test Playback L/R and all cues.
11. Load Record profile; verify names, target disk, and space.
12. Close unnecessary Windows/background applications.
13. Enable rack LOCK.
14. Save the final console and preserve recovery copy.

#25.2 During show

• Maintain one command owner per operational area.
• Monitor CPU, meters, ASIO, record and playback status.
• Avoid scan, ASIO topology changes, isolation regrouping, or untested graph edits.
• Use Fade/transition policies as rehearsed.
• Treat Original Editor Live Audio as delayed visual reference only.
• If an isolated plugin fails, contain first; reload only at an acceptable moment.
• Do not force restart Core while recording unless loss of the current recording is accepted.

#25.3 Post-show

1. Stop recording and allow finalization.
2. Stop playback.
3. Save final console only if the final state should become authoritative.
4. Export/copy recording sessions according to the production data plan.
5. Stop Server before copying LiveSoundRackData for backup.
6. Record any plugin/driver/network anomaly before changing configuration.

#26. Concise specifications

#27. Troubleshooting decision paths

#27.1 No server connection

Server tray running?
  ├─ No → start LiveSoundRack.Server.exe
  └─ Yes
      Core/Web reported running?
        ├─ No → normal supervised restart; inspect local status
        └─ Yes
            Direct http://server-ip:21011 works?
              ├─ No → check address and firewall path
              └─ Yes → discovery/VLAN/broadcast issue

#27.2 ASIO start failure

Interface powered/visible in Windows?
  ├─ No → hardware/driver recovery
  └─ Yes
      Another ASIO host owns device?
        ├─ Yes → close it
        └─ No
            Selected rate/buffer supported?
              ├─ No → choose supported values
              └─ Yes → stop/start, normal Core restart, driver reboot path

#27.3 No rack output

ASIO running
→ source routed
→ input meter
→ Input Gain
→ plugin crash/bypass/state
→ rack bypass/mute
→ output meter
→ unique ASIO output route
→ interface mixer/physical output

#27.4 Remote Original Editor failure

Matching plugin installed locally
→ exact version/build checked
→ LiveSoundRack.Client.exe open on the RACK screen
→ server/slot identity still valid
→ TCP control reachable
→ EditorHost allowed by firewall

#27.5 Remote RTA/meter failure

Original Editor open
→ Live Audio enabled
→ selected server slot has signal
→ UDP 21013 permitted
→ wired/network quality acceptable
→ plugin actually exposes meter/analyzer
→ Client latest-window processing is not overloaded by too many/heavy editors

#27.6 Playback silence

Track decoding/clock moving
→ Playback L/R assigned to Stereo rack
→ rack input meters
→ plugin/rack mute and gain
→ unique ASIO output routes

#27.7 Record cannot start

ASIO running
→ profile compatible with committed topology
→ at least one channel enabled
→ Record Names valid
→ path writable/free space

#27.8 Dropouts

Increase ASIO buffer
→ inspect CPU Monitor
→ remove/relax high-cost plugin modes
→ use slower DFB Response where supported and operationally acceptable
→ check RAM memory-pressure state
→ verify PDC/latency expectations
→ raise isolation transport blocks or reduce isolation
→ avoid Crossfade/full dual graph
→ check driver/DPC/USB/power/thermals

#28. Final production principles

1. Server Core is the audio authority. Clients are replaceable control surfaces.
2. Use a trusted private network. The built-in HTTP connection is not intended for direct Internet exposure.
3. Measure the final graph. Empty-rack stability does not predict production load.
4. Preserve exact plugin versions and licenses. State compatibility is vendor-controlled.
5. Treat PDC and isolation as latency design choices. They improve specific properties by adding delay/resources.
6. Route Playback explicitly. Playback L/R is a virtual input, not a direct hardware output.
7. Record to fast local storage and stop cleanly. The realtime path will not wait for a slow disk.
8. Crossfade requires double-graph headroom. Do not enable it from intuition alone.
9. Coordinate multiple operators. Last accepted authoritative command defines the state.
10. Back up with the server stopped. Preserve LiveSoundRackData, binaries, licenses, driver details, and a tested recovery console.