One product. Many forms.
Nucleic Core is the portable real-time foundation behind Nucleic instruments. It keeps the sound, timing, controls, and state that define a product coherent across hardware and software.
For product builders
Contracts, real-time boundaries, adapters, state, and qualification evidence.
See how it works →Why it exists
Hardware instruments, plugins, browser tools, and desktop editors often grow into separate implementations. Their timing changes, features drift, presets become incompatible, and fixes get repeated. The result is a family resemblance, not one reliable instrument.
Nucleic Core starts from a different premise: the musical product has one authoritative definition. Each edition adds only what its environment requires: an audio driver, a plugin host adapter, browser integration, a renderer, flash storage, or hardware controls. Not the same binary or interface everywhere, but the same product meaning, with the mechanism specialized per platform.
What's shared, what's not
Depending on the product, the portable definition can include synthesis, effects, sequencing, routing, parameter identities, MIDI behavior, presets, state transitions, timing rules, and screen presentation. A change to one of those behaviors belongs in the product, not in separate browser, hardware, and plugin copies.
Portable doesn't mean pretending every platform is the same. A browser AudioWorklet, a VST3 host, a Core Audio callback, and an STM32 interrupt operate under genuinely different constraints. Nucleic Core gives them common semantics while allowing different queue capacities, memory placement, device lifecycles, and scheduling mechanisms. Platform-specific systems (Core Audio, Core MIDI, RtAudio, RtMidi, VST3, Web Audio, Web MIDI, Canvas, Metal, libDaisy, filesystems, flash, USB, hardware buses) stay at the edge, translating external facts without redefining the product.
Share meaning. Specialize mechanism.
Composable layers, not one framework
Lower layers hold small, reusable concepts; higher layers compose them into complete products. An edition includes only the capabilities it needs, so small embedded hardware doesn't carry the cost of workstation features it never uses. Product code never calls Core Audio, browser APIs, Metal, or libDaisy directly; adapters translate at the boundary.
Product editions
Hardware · Native app · VST3 · Browser · Editor · Test runner
│
▼
Product definition
DSP · Sequencing · Routing · Parameters · State · Presets · UI composition
│
▼
Domain layers
Audio · MIDI · Control · Rendering · Storage
│
▼
Portable runtime
Time · Events · Scheduling · Bounded handoff · Snapshots · Diagnostics
│
▼
Thin platform adapters
Core Audio/MIDI · RtAudio/Midi · VST3 · Web APIs · WASM · Metal · DaisyReal-time discipline
Audio callbacks and embedded interrupts can't safely allocate memory, wait on locks, open files, log text, or do unbounded work. Nucleic Core uses fixed capacities, prepared state, bounded queues, deterministic event order, and compact diagnostics in those contexts. Rich work, configuration, rendering, persistence, device discovery, file or network access, stays outside the strict path, so a workstation edition can stay expressive while a microcontroller edition stays lean and predictable.
One product, several interfaces
Nucleic products can support two complementary interface families. Screen-native interfaces are designed for computers, tablets, phones, and embedded displays: responsive layouts, grids, scrolling, visualization, touch, keyboard input, accessibility. Control-panel interfaces are built around encoders, buttons, pads, LEDs, and compact displays, physical or a faithful virtual panel. Either family connects to the same authoritative product model, so a parameter changed from MIDI, a plugin host, a hardware controller, or a screen editor is applied once and reflected everywhere else.
Current native experiments use NanoVG over Metal; browser editions use Canvas2D. Product UI depends on Nucleic's own drawing contracts rather than either library, leaving room for alternative backends. This has meaningful multi-product evidence but remains experimental, not a complete universal widget framework.
Hardware and software as peers
The long-term model treats physical instruments, virtual editions, editors, and controllers as peers, not a primary product and its ports. A hardware instrument can gain a rich computer editor and a faithful virtual counterpart; a software instrument can gain a dedicated tactile controller; several surfaces can stay connected at once around one product state. A smart physical panel may use its own microcontroller to scan buttons, debounce switches, decode encoders, and drive LEDs, communicating logical events to the product host rather than handing over every electrical detail.
This isn't a hypothetical: earlier Nucleic/Groover experiments already had a working physical panel, a Pico bridge handling control events and LED feedback, and a browser/touch mirror of that panel. Nucleic Core doesn't import that old code, but it does treat what worked, and what didn't, as evidence. What remains is rebuilding and qualifying that panel behavior behind the current product contracts: an integration boundary, not a concept starting from zero.
Product proofs
Each product puts the foundation under a different kind of pressure: synthesis, sequencing, MIDI routing, audio processing, state, user interfaces, plugins, browsers, and embedded systems.
Nucleic Mono
A subtractive monosynth: oscillators, filter, envelopes, modulation, arpeggiator, MIDI control, and a tempo-aware stereo delay. Deterministic, native macOS, browser/WASM, VST3, and Daisy Pod editions share one product-owned editor across browser, standalone Metal, and VST3 adapters.
Some physical hardware, DAW, accessibility, and cross-OS checks remain deliberately open.
Play Nucleic Mono →Acid Cell
A TB-303-style acid voice and step sequencer with accent, slide, two voice models, and effects. The current engine runs as VST3, browser/WASM, and a Daisy Pod build profile, sharing a grid-based product view through Canvas2D and NanoVG/Metal adapters.
The sixteen-track sequencer, multiple per-track engines, and integrated hardware panel are product direction, not yet built. The Daisy build awaits physical qualification.
Play Acid Cell →MIDI Stage Router
An event-only performance tool distributing incoming notes across multiple MIDI destinations using stages, routes, traversal order, probability, conditions, and transformations. Proves Nucleic Core is not just a synth/DSP framework.
Signed/notarized distribution, physical Web MIDI qualification, and a Daisy edition remain separate work.
Open Stage Router →Nucleic Resonator
A polyphonic, MIDI-playable resonator that turns incoming audio into a tuned instrument. Its native macOS, VST3, and AUv3 editions share one real-time engine, state model, modulation system, and screen-native editor. Proves Nucleic Core as a foundation for audio effects, not only synths.
Signing, notarization, broader DAW qualification, and physical standalone MIDI validation remain separate work. No browser/WASM edition yet.
From working experiments to a connected ecosystem
The current synths and MIDI tools are the first visible cells of a larger system. The direction: hardware instruments with faithful virtual editions, software instruments with dedicated physical controllers, rich editors for standalone hardware, several connected surfaces staying synchronized around one product state, and eventually deeper sequencers and interactive audiovisual products where sound, events, and real-time graphics share one deterministic timeline. The architecture is deliberately allowed to evolve as new products teach the lab what actually belongs in common, rather than freezing a framework early to support products that haven't been imagined yet.
Current state and limits
Last updated 2026-08-12Nucleic Core has substantial working code and cross-platform evidence, but its internal API remains explicitly unstable. Product experiments are usable and increasingly complete; they are not yet a supported product catalogue. Some embedded targets have reproducible builds without complete physical qualification. Linux and Windows are not yet qualified. The physical smart-panel architecture remains active development.
Nucleic Core is internal R&D. Its API is not public or stable, and the source carries no public license. Nothing on this page is an SDK announcement.
| Area | Current state |
|---|---|
| Portable product engines | Working across four distinct product experiments |
| Browser / WASM | Playable editions for Mono, Acid Cell, and Stage Router |
| macOS native | Working for Mono, Stage Router, and Nucleic Resonator |
| VST3 | Validated engineering builds for Mono, Acid Cell, and Nucleic Resonator |
| AUv3 | Validated engineering build for Nucleic Resonator |
| Daisy-class embedded | Mono physically exercised; Acid Cell build awaiting full physical qualification; Stage Router planned |
| Shared screen UI | Working experimental contract across four products and multiple native, plugin, and browser adapters |
| Physical smart panels | Working prior Groover/Pico and virtual-panel evidence; current Nucleic Core integration and full ecosystem qualification remain active work |
| Public SDK / API | Not released; internal contracts remain unstable |
| Commercial releases | None claimed |
Build the instrument. Test the foundation.
Nucleic Core exists to make ambitious electronic music products easier to carry across hardware and software without losing their identity. Every real instrument exposes weaknesses an abstract framework would miss; every improved lower layer should make the next instrument more coherent, portable, and reliable. The work is early, but it's already playable.