makeIRLPCB engineering field guide

Vibecode AI hardware guides

Vibecode a MIDI Controller PCB with AI and Gate Checks Guide

Generate a MIDI controller carrier only with exact USB or DIN interface blocks, controls, scanning and LED power, ready for explicit human gate review.

Practical PCB integration · KiCad 9 · Manufacturing gate

Vibecoding a MIDI controller: what the generator can and cannot do

MakeIRL's generator treats a MIDI controller prompt as a self-contained project board. Current status: in envelope needs block.

Low-speed controls fit the intended envelope after verified input and MIDI/USB blocks exist. The current catalog has none; USB data and DIN current-loop details cannot be inferred.

Create a USB-powered controller with eight buttons, four exact potentiometers, two encoders, cataloged MIDI DIN output block, status LEDs, and no wireless or motorized controls.

MakeIRL V2 extracts a strict CarrierSpec from the prompt, applies a deterministic scope policy, resolves only cataloged blocks, composes deterministic connectivity and exact-MPN BOM data, emits KiCad artifacts, and runs the manufacturing gate. The language model does not invent pins, topology, parts, placement, routing, or substitutions.

What the prompt must specify

  1. USB and/or DIN MIDI role, exact connector/opto/output circuits, current-loop standard, controller block, firmware mapping, and latency target
  2. Control MPNs, matrix/ADC/encoder topology, pulls/filters, LED count/current, display, and calibration
  3. Panel datum, heights, knobs, jacks, mounting, enclosure, cable access, ESD, and end-of-line control test

Block plan:

  • Cataloged controller/module carrier
  • Verified MIDI DIN input/output and/or USB-device blocks
  • Verified button, encoder, potentiometer/ADC, LED/status, and panel connector blocks

Interfaces: MIDI current loop through verified blocks, USB Full-Speed MIDI when supported, GPIO/ADC human inputs. Power plan: USB or declared low-voltage input within the envelope, with LED/display budget; no phantom powering, battery, or motorized controls.

Layout priorities and gate checks

  • Reference all controls to the panel, isolate DIN input as required, keep LED scan current out of ADC references, and mechanically support jacks.
  • Freeze the board outline, mounting holes, connector faces, component height zones, test access, and keepouts before evaluating generated placement or routing.

Gate checks:

  1. S1Generated connectivity and schematic parity. Check DIN connector view/pins, optocoupler/output polarity and current, USB CC/data, every control map, LED resistors, and panel footprint alignment.
  2. S1Catalog and exact-MPN provenance. Every MIDI controller block, footprint, pin map, required companion, BOM line, and block-status claim must resolve to the pinned catalog version; the prompt cannot create missing hardware.
  3. S2PCB DRC, fabrication profile, and release identity. Run KiCad DRC and schematic parity, compare geometry with one quoted fab profile, regenerate Gerbers/drills/BOM/CPL from the approved revision, and inspect both local and supplier previews.

Human review, failure modes, and validation

  • Review MIDI electrical version, isolation, ground/shield, control feel, ADC noise, USB firmware, latency, panel fit, connector stress, and recovery.
  • A reviewer must check primary datasheets, exact symbol-to-footprint mapping, power and protection, return paths, connector orientation, mechanical fit, test coverage, and every gate waiver before release.

Failure modes:

  • A DIN jack's mating-view numbering can reverse the current loop, and LED scanning can inject noise into adjacent analog controls.
  • ERC and DRC can prove encoded consistency but cannot prove requirements, component source truth, analogue stability, RF/EMI, thermal margin, firmware, safety, compliance, or delivered product function.

Validation plan:

  • Exercise every control and LED, MIDI input/output across devices and cables, USB hosts if used, latency, chord/scan load, ESD, and panel fit.
  • Bring up first articles with current limiting, measure every rail before fitting expensive modules, program minimal test firmware, exercise every interface and fault assumption, and retain measurements against the released revision.

Refusal boundary and generator envelope

  • Refuse wireless, batteries, motors, audio paths, USB high-speed, or uncataloged MIDI/analog blocks.
  • A generated board does not prove MIDI firmware mapping or musical interaction quality.

The intended carrier envelope is 2-layer FR-4, at most 100 × 100 mm, at most 40 BOM lines, at most 12 V SELV and 2 A, with cataloged modules and low-speed I²C, UART, GPIO, slow SPI, or power-only USB-C connections. The current catalog is narrower than that intended envelope.

Deterministic policy refuses unsupported or hazardous requests, including mains, motors, lithium charging, RF design, switch-mode power, high-speed buses, excessive size/current, and unknown modules. A refusal is a safety and truthfulness result, not a failed attempt to improvise a circuit.

The current seed catalog contains ESP32-C3 carrier, USB-C power, and Qwiic/status-LED blocks at checked status. They have passed deterministic checks but are not yet physically verified through the documented two-lot bring-up ladder; pages must not call those current seeds verified.

The output is a gated design candidate for engineering review. Current placement/routing can still produce blocking or review findings, so a generated board is not automatically fab-ready, functionally validated, certified, or safe to order. MakeIRL does not autonomously place a fabrication order from a prompt. Human review, source and output inspection, gate resolution, order-specific fab confirmation, and physical bring-up remain required.

Generate a gated candidate, not a blind board

Try a MIDI controller prompt in the generator and review every gated artifact before ordering.

Generate a carrier board