#LiveSoundRack Quick Start Guide for Professionals

#Purpose

This guide is a commissioning and show-readiness procedure for an engineer who already understands ASIO, gain structure, plugin hosting, routing, and production networks. It identifies the user-facing entry points, establishes the server/client topology, configures the realtime path, and verifies recovery and persistence before the system is used in production.

LiveSoundRack is server-authoritative: Server Core owns the ASIO driver, rack graph, routing, plugin DSP/state, playback, recording, and console switching. Windows Client and the browser are control surfaces. Closing a client does not stop server audio.

#1. Process and executable topology

Normal server startup is therefore:

LiveSoundRack.Server.exe
  └─ LiveSoundRack.Server.Core.exe
       ├─ LiveSoundRack.Server.Web.exe
       └─ LiveSoundRack.Server.PluginHost.exe  [when isolation is enabled/required]

#2. Deployment topologies

#Single-machine system

Run Server and Windows Client on the same Windows machine. Use http://127.0.0.1:21011 for the browser. This has the fewest network dependencies and permits local Original Editors without remote preview transport.

#Dedicated audio server with remote control

Run LiveSoundRack.Server.exe on the audio server and use Windows Client or Chrome on a separate control computer. Prefer wired Ethernet, static DHCP reservation or static addressing, and a dedicated/private control VLAN when possible.

#Network ports

Chrome exposes server-hosted downloads in this order: Client, then Plugin Editor Host. The Client app hides this top information row and starts at the main control tabs. Open only the ports required on trusted network segments. Do not forward them directly from the public Internet. The built-in Web UI uses HTTP rather than built-in TLS. Use a VPN, network segmentation, or an appropriately configured secure gateway for untrusted-network access.

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.

#3. Commissioning sequence

Use this order for a clean initial deployment:

1. Install and verify the audio interface and ASIO driver.
2. Install and license all server-side VST3/CLAP plugins.
3. Place portable packages, when supported, in the server sibling VST3\ or CLAP\ drop folders.
4. Start LiveSoundRack.Server.exe.
5. Connect with Windows Client or http://server-address:21011 in Chrome.
6. Configure the trusted control network and Windows Firewall rules.
7. Decide whether to enable SETUP → SYSTEM → LiveSound.App Performance Power Plan. It is off by default. If enabled, confirm the shared prompt on one connected Client. Verify AC power, cooling, and thermal behavior before the full-load test. The setting may be changed while ASIO is running, but any change should be validated under the intended production workload.
8. Select ASIO device, sample rate, and buffer with output muted.
9. Scan plugin roots and complete Waves Prewarm if offered.
10. Confirm CPU headroom, physical RAM, and that the memory-pressure marker is Normal.
11. Define Plugin Process Isolation, transport latency, Audio Transition, and Console Change Mode before graph construction.
12. Review CPU Steering's six current groups and Runtime Priority's four selectors; retain defaults unless measurement supports a change.
13. Build racks, routing, plugin chains, sidechains, and PDC.
14. Set and document DFB Response for every supported De-Feedback 1.1.4 use.
15. Route and test Playback L/R if required.
16. Configure and test Record profiles if required.
17. Save a baseline console and rack/plugin presets.
18. Stop Server, back up LiveSoundRackData, restart, and verify deterministic restoration.
19. Test normal Core restart, client reconnect, shared prompts, memory-pressure add confirmation, and required remote Original Editor workflows.

#4. ASIO configuration and baseline verification

In SETUP → ASIO:

1. Click Refresh and select the intended ASIO endpoint.
2. Select a driver-supported sample rate and buffer size.
3. Leave MMCSS (ASIO/engine) enabled unless a controlled test demonstrates a reason not to.
4. Start ASIO and confirm input/output channel names and reported latency.
5. Verify stable operation with an empty rack graph before adding plugins.

Operational tradeoff:

• Smaller buffers reduce I/O and plugin-chain latency, but reduce CPU scheduling margin.
• Larger buffers increase stability and isolation transport time, but add latency.
• Plugin-reported latency, rack/global PDC, sidechain alignment, and isolated transport latency add to the ASIO baseline.

Auto-start ASIO is a next-start policy. A successful automatic start requires a remembered valid device, rate, and buffer. If hardware enumeration or driver capabilities change, perform a manual selection and save again.

Do not change ASIO device, rate, or buffer during a critical program segment. Stop recording, mute the system, and stop ASIO before maintenance changes.

#5. Plugin catalog and Waves Prewarm

#Catalog scan

In SETUP → PLUGINS:

• Add server-accessible VST3 and CLAP roots.
• Scan outside the critical show period.
• Review discovered plugins and scan status.
• Use Exclude/Include to control selection-list visibility.
• Use Edit to normalize displayed vendor/category metadata; this affects catalog presentation only.

Remote users browse the server filesystem. A path that exists only on the client is not a valid server scan root.

#Waves Prewarm

When a scan finds an eligible Waves VST3 and Plugin Process Isolation is Off, LiveSoundRack can offer Waves Prewarm. When accepted, the LiveSoundRack server restarts automatically once while the selected Waves component is initialized. ASIO is unavailable briefly during the restart.

Prewarm conditions:

• ASIO/audio is stopped.
• Isolation mode is Off.
• An eligible Waves VST3 is present.
• OPTION → Auto-initialize Waves (Server) is enabled and the offered action is accepted.

Keep the LiveSoundRack Tray app open during the sequence. Confirm that the Server returns, the Waves plugin instantiates, and its license environment is ready before saving the baseline Console File.

#6. Set transition and isolation policy before graph construction

#Audio Transition Time

This smooths discontinuities associated with plugin insertion/replacement, bypass/mute, routing, and engine start/stop. Available choices include block-relative values and 10 ms, 100 ms, or 1 s.

Use enough transition time to control clicks without making operator actions feel unresponsive. It is unavailable when process isolation is active.

#Console Change Mode

• Instant — immediate graph switch; lowest transition resource use.
• Fade — fades out, loads the target console, then fades in.
• Crossfade — runs old and new console graphs together and crossfades them; smoothest continuity, highest temporary CPU/RAM demand.

Crossfade is unavailable while plugin isolation is active. Validate worst-case double-graph load with adequate CPU headroom before using it live.

#Plugin Process Isolation

Transport Latency is configurable from 0 to 10 ASIO blocks; the first-run value is 2 blocks. Zero minimizes nominal transport delay but provides the least scheduling margin. Increase it when isolated processing reports underruns or instability, accepting the added latency.

In any isolation mode:

• Audio Transition Time is disabled.
• Console Crossfade is disabled; use Instant or Fade.
• A shared host failure can affect every slot assigned to that host.
• A crashed slot offers Empty, Bypass, Reload Plugin, and Acknowledge Crash actions.

#7. Rack and routing commissioning

#Current signal path

Physical ASIO / Playback / Test Signal
  → input route
  → rack Input Gain
  → Automixer
  → ordered plugin chain and sidechain taps
  → rack Output Gain / Mute / Bypass
  → global PDC alignment
  → output route
  → ASIO output

#Rack configuration

For each rack:

1. Set Mono or Stereo width.
2. Assign input sources.
3. Establish nominal Input Gain and verify pre-plugin meter behavior.
4. Insert plugins in processing order.
5. Assign output destinations.
6. Set Output Gain and Mute state.
7. Decide Automixer and per-rack PDC policy.
8. Name and color the rack for operator recognition.
9. Verify reported rack latency.

Limits and constraints:

• At least one rack remains.
• Up to 32 plugin slots are available per rack.
• The server accepts a large rack count, but practical capacity is determined by ASIO topology, plugin DSP, CPU, RAM, process isolation, and UI manageability.
• A single input source can feed multiple rack inputs.
• Each rack input destination has one source.
• Each physical ASIO output destination can be owned by only one rack output.
• Mono uses the left path; right-side input/output controls are not active.
• A rack referenced by an active sidechain cannot be removed until that route is disabled or reassigned.

RACK toolbar indicators and controls:

• ERROR: n is the sum of ASIO OverLoads, DSP Overruns, and Dropout Signals. Click it to inspect the three 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, not only the LiveSoundRack processes.
• ▲ / ▼ collapses or expands the Rack area.
• Remove Last (n) removes the last Rack; n identifies the Rack that will be removed.
• DFB Response — appears only for supported De-Feedback 1.1.4 and lets you choose the feedback response speed.
• RAM warning — orange/red decoration is the system commit-pressure indicator. Plugin Add confirmation is gated separately by the latest valid commit reading and begins at 80%, so it can precede the orange two-sample Warning marker.

#Virtual sources

Available non-hardware sources include:

• Playback L / Playback R
• Pink Noise
• 300 Hz, 500 Hz, 1 kHz, 2 kHz, and 4 kHz sine signals

Test signals are continuous while routed and ASIO is running. Route them with rack output muted, establish a low output gain, then unmute deliberately.

#Rack structure operations

• Add/remove the last rack.
• Drag racks to change display order.
• Drag plugins between slots/racks.
• Copy Rack / Paste Rack transfers rack processing settings and plugin state subject to plugin availability and sidechain preflight.
• Reset Rack keeps input/output routing and rack width, while clearing other rack settings and plugins.
• LOCK protects structural editing after commissioning.

#8. Plugin operation, state, and presets

#Slot actions

Click an empty slot to open the common slot menu and the VST3/CLAP selection list. On an empty slot, unavailable actions are disabled; Paste Plugin is enabled when the clipboard contains a plugin, and Load Plugin Preset remains available. For a healthy loaded slot:

• Left-click opens the Original Editor.
• Right-click provides Empty Slot, Bypass Plugin, Original/Generic Editor, Copy/Paste Plugin, Save/Save As/Load Plugin Preset, and isolated-host reload where applicable.
• Drag the slot to reorder or move the instance.

#Plugin presets

A plugin preset stores one plugin's state and identity. Loading requires the corresponding server plugin. Save a named preset after establishing known-good parameters and verify restoration before depending on it during a show.

#Rack presets

A rack preset stores the rack processing configuration: name, width compatibility, gains, bypass/mute/automixer/PDC states, slot layout, plugin identities/versions, parameters, plugin state, and sidechain definitions. Loading targets a rack of matching width and retains that target's physical input/output routing. Invalid external sidechain references are cleared. Existing target plugins require confirmation before replacement.

#Console files

A Console File is the complete show-level Rack, routing, and plugin configuration. Left-click Console File to open the recent Console File list and select a Console. Right-click it to open Load, Save, and Save As. Use the X beside a recent item to delete that Console File after confirmation. Autosave supports 10, 30, or 60 seconds.

Use console transition modes intentionally. Before loading a different console, confirm output safety, plugin availability, version compatibility, and sufficient CPU for the selected transition.

#9. PDC and sidechain workflow

#PDC

Each plugin can report latency. Per-rack PDC maintains timing within the rack and its sidechain relationship. Global PDC aligns rack outputs to the highest active rack latency.

PDC improves phase/time alignment but adds delay to lower-latency paths. Disable it only when the latency tradeoff is understood and the resulting timing has been measured.

#Sidechain

Open the plugin's Original Editor and use the top-bar Sidechain controls when the plugin exposes an external sidechain input.

• Select an eligible external rack source.
• Choose the server-presented source path; available sources may be raw or processed according to the route.
• Confirm the route and timing with PDC enabled as required.
• Disable the route before removing its source rack.

A rack preset or paste operation performs a sidechain preflight. A route that cannot be valid in the target graph is cleared or requires confirmation rather than silently attaching to an unrelated rack.

#10. Local, generic, and remote Original Editors

#Generic Editor

The Generic Editor is parameter-oriented and browser-native. It requires no client-side plugin installation and does not display manufacturer-specific graphics or realtime analyzers. Isolated PluginHost slots now publish parameter descriptors through a bounded non-realtime metadata snapshot, so names/ranges remain available without changing audio transport.

#Original Editor

The Original Editor uses LiveSoundRack.Client.EditorHost.exe and a locally loadable matching VST3/CLAP component. Use the exact same plugin version/build as the server whenever possible.

The Client creates sibling VST3/CLAP folders. EditorHost resolves the exact server path when it exists locally, then a local catalog match, then scans the sibling drop folders and standard Windows installation locations by format and stable identity. Prefer the vendor installer; standalone VST3 requires the complete .vst3 container.

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. When the Client opens an Original Editor, the shadow plugin is not in the production DSP return path; parameter changes synchronize to the authoritative server slot.

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

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

#Remote Live Audio

Enable Live Audio when the vendor GUI needs input-driven meters/RTA. ServerCore sends post-PDC/pre-plugin main and optional sidechain audio by UDP 21013.

Current contract:

• 48 kHz planar float32;
• event-driven latest-only processing with no backlog catch-up or synthetic silence blocks;
• about 2 Mbps Mono and up to 8 Mbps Stereo plus sidechain.

Slow shadow DSP or network loss drops stale visual windows instead of delaying the stream. Shadow output is discarded and never enters production audio.

#11. Playback commissioning

Playback creates the virtual stereo source Playback L/R. Route it through a stereo rack before expecting hardware output.

Supported extensions accepted by the playback backend are:

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

The server opens the files; remote clients must select server-accessible paths. Decode support also depends on Windows Media Foundation codecs available on the server.

Commissioning steps:

1. Create a stereo playback rack and route Playback L/R to it.
2. Route the rack to dedicated or shared downstream outputs as designed.
3. Add representative files from the production storage volume.
4. Verify Play, Pause, Stop, Previous, Next, seeking, and end-of-list behavior.
5. Select the required play mode: stop after track/list, repeat track/list, shuffle list, or shuffle all lists.
6. Set playback volume and Gain Transition.
7. Enable AutoGain only after checking analyzed values and the intended artistic result.
8. Set the Safety Limiter ceiling; the default UI selection is -1.5 dBFS.
9. Configure Play-in, Pause-out, Stop-out, and Change in/out/cross fades.
10. Verify all playlist tabs and tab order.

AutoGain follows ITU-R BS.1770 / EBU R128 behavior with a -23 LUFS target. Analysis is asynchronous and measures at most the first 300 seconds. Waveform data uses 1024 min/max bins and is unavailable for files longer than 600 seconds; playback remains available. Clean Cache removes orphan analysis data and is permitted only while ASIO is stopped.

The limiter is before the rack. Subsequent plugin gain, rack gain, or routing summation can still exceed full scale.

#12. Recording commissioning

Recording can capture:

• Raw physical ASIO inputs before rack processing.
• Playback L/R virtual inputs.
• Final ASIO output channels after rack processing and routing.

For each enabled row, assign a valid Record Name. Start requires running ASIO and at least one enabled channel. Channel configuration and profile actions are locked while recording.

Files are written to the server as separate mono, 32-bit IEEE-float WAV files at the active ASIO sample rate. Each file is split before its data section reaches 2 GiB. A session is organized as:

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

The realtime callback queues blocks without waiting for disk I/O. The writer queue holds 256 ASIO blocks; slow or saturated storage can produce dropped recorded blocks. Use a fast local volume, check free space, and observe recording status during a full-duration rehearsal.

Record profiles are bound to the committed ASIO topology. A different device identifier or physical channel count can reject the profile. Channel-name changes with the same indexed layout may be accepted with a warning. Always reopen and verify the production profile after driver, firmware, or interface changes.

Stop recording before Core restart or shutdown and allow file headers/queued blocks to finalize.

#13. Persistence, backup, and naming rules

The server creates its working data beside LiveSoundRack.Server.Core.exe:

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

The server directory must be writable. Avoid an installation location that blocks application writes unless permissions are deliberately configured.

Back up with the server stopped:

• The entire LiveSoundRackData directory.
• Local VST3 and CLAP drop folders if used.
• Plugin installers, exact versions, and licensing information through the vendor's supported process.
• ASIO driver version and interface configuration records.

Managed names accept Unicode letters/digits, spaces, _, -, and .; maximum length is 128 characters. Names cannot start/end with whitespace, end with a period, equal . or .., use Windows reserved device names, or include managed file extensions. Enter console names without Console. and enter record names without .wav.

Do not edit state, transaction, cache, or temporary files while Server Core is running.

#14. Recovery tests before production

Perform these tests with monitoring at a safe level:

1. Close and reopen Windows Client; confirm server audio continues.
2. Disconnect/reconnect the control network; confirm Core continues and clients resynchronize.
3. Normal-restart Core from the SERVER tab; confirm expected interruption and state restoration.
4. Force restart only in a controlled test; understand that it can interrupt active recording and state capture.
5. Crash/reload a noncritical isolated plugin and verify the selected containment boundary.
6. Load the baseline console from a clean Server start.
7. Test console Fade or Crossfade with the heaviest practical graph.
8. Verify remote Original Editor local-path/catalog/scan fallback, parameter synchronization, sidechain selection, and optional latest-window Live Audio.
9. Record long enough to validate storage throughput and file splitting strategy.
10. Play every codec and sample-rate family used in the show.
11. Trigger one low-risk shared confirmation from two clients and verify first-response-wins/dismissal behavior.
12. Reboot Windows and verify Start with Windows, scheduled reboot, remembered settings, and ASIO auto-start policy.

Use Restart LiveSoundRack.Server.Core.exe before Force Restart. Both interrupt audio; the forced path is for an unresponsive Core.

#15. Production constraints summary

#16. Show-day checklist

#System

• Correct Windows power, USB, network adapter, and update policies.
• Performance Power Plan state documented; AC power, cooling, and thermal behavior verified.
• Server startup and optional scheduled reboot verified.
• License state verified; no reliance on an expiring demo.
• Firewall rules restricted to required trusted interfaces.
• Wired control path tested; discovery and direct address both known.

#Audio

• Correct ASIO device/rate/buffer/MMCSS.
• Stable empty-graph and full-graph CPU tests.
• RAM pressure Normal; plugin-add warning path rehearsed.
• CPU Steering six-group and Runtime Priority four-selector settings documented.
• Input/output line check at low level.
• PDC and sidechain phase/timing verified.
• Isolation and transition modes fixed for the show.
• Supported De-Feedback 1.1.4 DFB Response settings fixed and documented.
• Test signals removed from live routes.

#State

• Production console saved and reloaded.
• Console Autosave policy deliberate.
• Plugin/rack presets tested.
• LiveSoundRackData backup available.
• Exact plugin versions documented and licensed.

#Playback and recording

• Playback L/R routed.
• All media decoded and analyzed in advance.
• Play mode/fades/limiter verified.
• Record profile loaded, channel names checked, storage performance and free space confirmed.

#Operations

• Rack LOCK enabled after configuration.
• Normal and forced recovery responsibilities assigned.
• Multiple operators agree on command ownership.
• Remote Original Editor and Live Audio used only when required.