Architecture
What Is ONE-X?
Section titled “What Is ONE-X?”ONE-X is an ecosystem for building and playing sample- and synth-based virtual instruments — pianos, string sections, synths, drum machines, whatever the underlying engine can do. dBdone doesn’t build instruments; it builds the tools and infrastructure that let authors build them and get them to musicians.
Three parties, three concerns:
- End users load finished products into their DAW and make music with them. They never see how a product was built.
- Authors (also called vendors) — this is you, the audience for the rest of this documentation — design and build instruments: sound design, scripting, and UI.
- dBdone supplies the tools (plugin, editor) and the infrastructure (accounts, licensing, distribution) that connect authors to end users.
Two Tools, One Engine
Section titled “Two Tools, One Engine”Whatever an author builds is played back by the exact same software an end user has installed — there is no separate “preview” engine:
- The plugin is a DAW plugin (VST/AU) or standalone app that loads products and plays them. Whichever product is loaded determines what the plugin is — piano, strings, synth, drum machine, and so on.
- The editor is a standalone authoring app: sample mapping, RT scripting, and the UI Builder all live here.
author end user │ │ ▼ ▼ ┌────────────┐ product (.oxl) ┌────────────┐ │ editor │ ──────────────────────────────▶ │ plugin │ └────────────┘ └────────────┘Live Editing
Section titled “Live Editing”The plugin is always responsible for playing back a product, whether it’s finished or still in production. A plugin instance only switches into edit mode if it detects an already-running editor: every change made in the editor — sound design, scripting, UI layout — is then reflected in the plugin immediately, over a live connection, and it’s the exact same signal path the end user will eventually hear.
Two ways to run that connection:
- The editor auto-launches the standalone plugin, so authoring is self-contained.
- Or the author works inside a DAW session instead: start the editor, close the standalone it auto-launched, then open the DAW project — the plugin starts in edit mode and re-establishes the live connection. This lets authoring happen with the editor comfortably on a second monitor instead of a tiny plugin window, though it’s a less-polished path today since the default flow above covers most cases.
┌─────────────┐ live connection ┌────────────────────────────┐│ editor │◀ ── ── ── ── ── ── ─▶│ plugin (edit mode) ││ sound design, │ │ standalone — or — ││ RT scripting, │ │ VST/AU inside a DAW session ││ UI Builder │ │ │└─────────────┘ └────────────────────────────┘From Instrument to Install
Section titled “From Instrument to Install”Once an instrument is finished, publishing packages it into a product: a folder with three files holding everything — patch, assets, and metadata. Authors distribute that folder however they like. Installing it is a copy operation: the end user drops it into one of their library folders, directories the plugin scans for installed products. Library folders are configured once in the plugin, typically on a dedicated drive for professional setups, then rescanned whenever new products are added.
Free vs. Commercial, and DRM
Section titled “Free vs. Commercial, and DRM”Products can be free or commercial:
- Free products need no setup and always carry a mandatory “free” tag in the UI.
- Commercial products require the end user to enter a license key. Authors generate these keys in any quantity from their ONE-X account page and sell them on their own terms.
- For commercial products, authors can additionally enable DRM protection: the product’s entire asset container — samples, wavetables, scripts, UI graphics, MIDI files, everything — is encrypted. A user- and machine-specific decryption key is generated the moment the product is registered with its license key.
Beyond Sound Packs
Section titled “Beyond Sound Packs”ONE-X is built for polished, professional products, not just sample libraries with a generic UI. A complex internal sound structure can be exposed through a handful of purpose-built macro controls, so end users get an instrument-specific playing experience rather than a wall of raw parameters.
Scripting and UI, in Brief
Section titled “Scripting and UI, in Brief”Two systems make that polish possible:
- RT scripting lets authors insert Lua processors into the real-time signal path — legato logic, arpeggiators, MIDI file playback, or anything else the engine doesn’t do natively.
- The UI Builder works in two layers: a declarative, forms-based layer (edited visually or as YAML) for fast, simple UIs, and a Lua scripting layer per form for dynamic controls and custom logic when forms alone aren’t enough.