From module to hardware

The Engine's pedal workbench lets you evaluate a canonical module as a hardware product: choose a board profile, map physical controls, build an artifact and compare its behavior before connecting a board. Pi 5, Pico 2, Daisy Seed and ESP32-S3 have experimental target lanes. Physical-device qualification is still ahead.

In the Help Center: Controllers, pedals and hardware for what works with controllers and devices today.

Keep the sound in the module

Your module owns its Processor or Graph, ports, parameters, state, presets and resources. A pedal project references it through pedal.jsonc. It selects a profile and maps logical knobs and switches to parameter paths. The device host supplies I/O and scheduling; you do not write a second DSP implementation in the pedal project.

Read Hardware architecture for the host boundary and Hardware platforms and profiles before choosing a board.

Start from your module

In the maru dev workbench, choose Put this on hardware. Select a name and a board/control study, review its audio and MIDI fit, then create the project. It opens at Sketch in the regular workbench. Timing and memory headroom remain unavailable until measured; every choice states whether its inputs are virtual and that it has not been verified on a real board.

The CLI uses the same creator. List the boards and profiles that fit a module, then create the project with one of them:

maru hardware boards guitarabin
maru hardware create my-pedal --module guitarabin --profile <profile>
maru dev my-pedal --open

maru hardware --help lists the hardware commands and their options. Existing folders are refused. Creation references the canonical module; it does not install or flash a device. Local Studio agents call the same typed operations. Hosted Studio does not create hardware projects on your computer.

Work in the pedal workbench

The workbench exposes the module face, virtual controls and mappings, connected-device inventory, Delivery and saved run history. In Design, drag controls on the panel, add controls or groups within the profile's capacity, and edit parameter or fixed-note bindings. Named edits save to pedal.jsonc, which remains directly editable. A virtual knob is useful configuration evidence, not proof of its physical ADC path.

In Delivery, run Build, Emulate and Run release audit. Audio checks compare fixtures and block sizes; MIDI modules exercise event streams and stuck-note behavior. Reports distinguish host-native, emulator and device results. A build can succeed while a release audit remains blocked.

The release audit does not install or flash a board. Explicit device installation is a separate stage.

For a profile with structured wiring, the workbench produces its pin table, connection SVG, Maru JSON connection list, BOM CSV and assembly drawing. These are proposed development connections. Design's Build & assembly disclosure lists unresolved components and circuits. The BOM includes those unresolved entries; it is not a ready-to-order kit while blockers remain. Codec analog circuitry, power and a production PCB still need electrical validation. Panel exports show placement and planning clearance; unspecified mounting holes are never guessed. Fabrication export refuses while qualified circuit and manufacturing inputs are missing.

Choose a useful first effect

Start with the gain fixture to check transport, codec routing and telemetry. Then evaluate one stock effect, such as distortion or phaser, before combining them. Use clean guitar, sine/sweep, impulse and silence, with parameter changes while audio runs. Compare against the same module's fresh reference Program.

FX Mini already provides a compact musical chain, distortion → tone → delay, with a fixed 48 kHz mono Processor. Check that the chosen adapter accepts that channel layout and measure its complete delay state. A source-state scan at 48 kHz found 192,136 bytes in typed-array backing buffers, before objects, generated adapters and runtime overhead. Its serialized-state limit is not its runtime memory budget. The MCU stereo adapter may need a shared host extension before this mono module can use it.

Multifx already includes phaser and distortion in its canonical effect engine. A two-effect preset is a useful Pi experiment, but its current allocation strategy makes it a poor first MCU fit test. Prepare a bounded configuration at that existing owner before promising a small-board multieffect. Disabling a delay or reverb does not necessarily release its prepared state.

Move from emulation to the board

Use Detect, then the target's Install or Flash stage for the exact artifact you evaluated. Pi uses SSH installation; Pico 2 uses USB BOOTSEL/UF2; Daisy uses USB DFU; ESP32-S3 uses an explicit serial port and the verified ESP-IDF flash package. Follow the selected profile's wiring and recovery instructions. The workbench reports missing tools or devices instead of inventing a successful device run.

After delivery, verify device identity and artifact readback, exercise the real controls and MIDI path, record input/output, measure cycles/deadlines and round-trip latency, then run a soak and recovery test. Keep board and codec revisions with the result. Emulator output parity alone cannot answer whether a pedal feels responsive, is quiet or survives an update.

This workflow is under development. Current static realtime and MCU performance findings remain release blockers. Browser audition, cross-compilation and successful flashing are useful milestones; device qualification requires the full measured result.