Skip to content
Iblis

Iblis technology overview

Iblis is a local-first AI music workstation for Windows 11. It is designed to keep the creative work on the musician's machine while making the expensive or replaceable parts — music engines, analysis tools, visualizers, and skins — independent packages rather than permanent shell features.

This page is deliberately both customer-readable and specific enough for a technical reviewer to identify practical improvements. It distinguishes what is shipping from what is designed but not yet delivered.

What you can use today

The current public installer is 0.2.0-alpha.10. A larger alpha.11 shell candidate is committed and tested locally, but remains behind its recorded Windows usability soak. It adds Library previous/next transport, pitch-safe speed controls, selectable waveform and volume presentations, clearer target metadata, and the first BPM/key processor contract. It does not include a working BPM/key detector or frequency-coloured waveform.

The system in plain English

Svelte user interface
        |
typed contextBridge IPC
        |
Electron main process ---- signed catalog and update checks
        |
supervised localhost sidecars
        |
music engine / future processors / future image and stem tools
        |
immutable track files + small verified sidecars

The renderer is intentionally only the interface: it has no direct filesystem or network access. Electron's main process owns local storage, plugin lifecycle, approved network activity, and typed IPC boundaries. Native tools run as supervised localhost sidecars on random high ports; they are not handed to the renderer as general executables or filesystem paths.

That separation gives Iblis practical flexibility: a new engine, analyzer, or visualizer can evolve without turning the UI into a collection of special cases. It also makes failures more containable: a sidecar can be health checked, restarted, rolled back, or stopped without treating the renderer as a trusted runtime.

Music generation track

The shipped engine is ACE-Step 1.5 packaged through the C++/GGML-based acestep.cpp runtime. It is built for Windows in a controlled workflow and uses CUDA on compatible NVIDIA hardware, with CPU fallback. The current pack uses a pinned native binary plus GGUF model assets: a Qwen3-based language model plans audio codes, then a diffusion transformer synthesizes audio and a VAE decodes it. The host persists the effective request, model identity, seeds, timing, and bounded phase trace beside the completed track.

Generation is deliberately serial. A queue entry becomes immutable when it is accepted, so a later UI edit cannot silently change a take in progress. Stop, timeouts, crash recovery, and engine install/rollback all meet at scheduler boundaries rather than competing for the same sidecar. The available validated recipe is Turbo at eight steps; other exposed Turbo step counts are clearly experimental, not a pretend higher-quality model tier.

The engine is one plugin, not Iblis itself. Future engines can use the same host contract if they meet the Windows packaging, local-only, provenance, license, and lifecycle requirements. A future engine may require a native build, but ordinary shell features and model-asset changes do not.

Playback and rendering track

Finished WAV audio is exposed to Chromium through a narrow local iblis-track:// protocol. The main process validates the WAV container and serves exact GET, HEAD, and byte-range responses; the renderer receives a track identity rather than a path. This is what makes seeking and HTML audio metadata dependable without copying large audio buffers across IPC.

A packaged worker derives a compact analysis.v1.json sidecar from supported PCM and IEEE-float WAV files. It records min/max peak partitions, level and clipping facts, source identity, and conservative audible/silent bounds. The player uses those facts for a true waveform, played position, and optional silence shading while preserving the original master file. It is not a fake decorative waveform.

The global player survives navigation, provides previous/next Library travel, pitch-preserving 0.5x–2x playback, explicit target metadata, and selectable peak/timeline plus volume-control presentations. These settings are local and skin-aware. A SkinContract supplies the semantic colors, spacing, and control tokens; plugins consume those tokens instead of owning a palette.

Frequency-coloured waveforms are planned, not shipped. Peaks only describe amplitude, so they cannot honestly be recoloured as bass/mid/treble content. That feature needs a second, bounded raw-PCM spectral sidecar and new semantic low/mid/high skin tokens before it can be presented as musical information.

Analysis and future processors

Iblis now has a versioned processor protocol for BPM and key detection. It supports bounded normalized results, alternatives, nullable confidence, provider/version/source provenance, and cancellation that releases the input before deletion or an update can proceed. Requested BPM/key are stored as generation targets and are visibly labeled as targets; they are not detector output.

No detector has shipped. Automatic analysis still needs a durable nonblocking scheduler, result store, explicit provider settings, and a Windows-native implementation that passes an accuracy, licensing, and cancellation gate on a rights-cleared labeled corpus. Stem splitting, mastering, image generation, and plug-in visualizers follow the same replaceable-processor direction.

Update, privacy, and trust model

The shell uses an Electron updater feed with a SHA-512 installer checksum. Plugins and skins use an Ed25519-signed catalog plus SHA-256 checks for every asset. New versions install in versioned directories and switch through an atomic current.txt pointer, so a failed activation leaves the previous version available for rollback.

Iblis is offline by default: prompts, lyrics, tracks, and Library metadata stay local. The renderer never contacts the network. Update checks and any user-enabled developer diagnostics are explicit exceptions with narrow main process handling; there is no account system or silent telemetry in v1.

Security model

Iblis is built to run untrusted-by-default: it downloads model weights, plugins, skins, and community-trained styles from the internet, so every one of those inputs is treated as hostile until it proves otherwise. The design leans on a few layered principles rather than a single perimeter.

Everything executable or authoritative is signed, and verified over its exact bytes. The plugin and style catalogs, the release feed, and each entitlement are Ed25519-signed; the signature is checked against the raw bytes before anything parses them, and every downloaded asset is additionally pinned to a content hash (SHA-256 for assets, SHA-512 for the installer). A tampered or substituted file fails the hash and is discarded, so a compromised mirror or a redirected download can relocate bytes but never swap them.

The window that draws your project has no reach. The renderer is network-free and path-free: it cannot open a socket or touch the filesystem directly. Everything crosses a single typed IPC boundary into the Electron main process, which is the only place privileged actions happen, each behind an explicit, validated entry point. Native generation and analysis engines run as separate localhost sidecars, not inside the UI.

Entitlements are cryptographic, per-account, and hardware-bound. A product key activates into a short-lived, server-signed lease that the app verifies locally, so a lease cannot be forged and expires on its own. Activation is bound to the machine's hardware fingerprint, which means copying an activated profile to another computer does not clone a working license, even fully offline. Revocation propagates within the lease window; sensitive actions re-check online opportunistically.

Community content is validated by independent, redundant checks. A community style is a machine-learning adapter, and Iblis refuses anything that is not exactly the safe tensor format it expects: file headers are validated against strict bounds and an allow-list, and formats that can carry executable payloads are rejected outright. That same check runs at more than one layer (on upload, and again on the device before a style is admitted), so a single missed edge case is not a single point of failure. File paths inside signed packages are constrained so an archive cannot write outside its own staging area. Upload and abuse quotas are tied to a signed, per-account identity rather than a device-supplied identifier, so limits cannot be reset by spoofing.

Secrets and privacy are structural, not optional. Signing keys live only on the server, never in the shipped app or the repository, and rotate by key id. On the client, a product key is sealed by the operating system keystore at rest. There is no account system, no analytics, and no silent telemetry; the only network traffic is signed update and catalog checks plus anything you explicitly opt into. The security posture is reviewed on a schedule, and fixes ship through the same signed release pipeline as every other change.

Useful review questions

An outside engineer or AI advisor can give useful feedback by keeping these constraints in view:

  1. Does an idea belong in the shell, or should it be a signed plugin with a versioned contract?
  2. Does it keep the renderer path-free and network-free, with a typed IPC boundary through Electron main?
  3. Can the result be reproduced and labeled honestly with model/provider, source hash, configuration, and confidence rather than inferred labels?
  4. Can cancellation, deletion, update, and rollback occur without a native process retaining a file handle or changing immutable source audio?
  5. Does a new visual treatment use semantic SkinContract tokens instead of hardcoded colors, and does it avoid implying analysis that has not happened?

For the exact contracts and release gates, see the public roadmap and the linked project documentation in the repository.