LIVE about the L1V3 BOX: A FULLY PROGRAMMABLE MIDI ROUTER
Explore the L1V3 Box programmable MIDI router with Pascal: Lua rules, USB host, routing, an Octatrack performance example and the prototype development.
The L1V3 Box is Pascal’s attempt to solve a problem that shows up when a hardware performance grows: MIDI messages need to reach some devices, avoid others, and sometimes change before they arrive. Rather than assemble a chain of mergers, splitters, and filters, he is prototyping one programmable hub for the whole rig. This live interview follows the design, software, and tradeoffs as Pascal explains them; it is not a finished-product manual.
Why put a programmable box at the center?
Pascal’s live setup is hardware-based. An Elektron Analog Rytm is his main sequencer, and an iPad is used for touch-oriented work such as granular synthesis, not sequencing. As he added controllers and sound modules, he needed messages to travel selectively. A merge combines streams; a splitter sends a stream to several destinations; filters keep unwanted message types from affecting a device. With many separate boxes and cables, setup became slow and failures multiplied.
His goal is to centralize those jobs and add transformation. A rule can take an incoming value and calculate a different outgoing value, or convert one kind of MIDI message into another. For example, one key press could send several Program Changes to different machines when he changes the track he is performing. He had considered a commercial block-based MIDI router, but found it could not handle SysEx, which matters for instruments such as his Access Virus. The L1V3 concept is meant to accommodate older gear and more customized routing.
Five physical MIDI ports, plus USB host
The prototype discussed has five TRS MIDI inputs and five TRS MIDI outputs. The first prototype used five-pin DIN connectors; Pascal switched to TRS after musicians at Superbooth 2023 said they preferred smaller connectors that take less panel space. He explains that TRS carries the same MIDI signal in this context, but Type A and Type B wiring had been a compatibility problem across manufacturers. His circuit was designed to support both types.
USB host expands the number of devices beyond the DIN/TRS connections. Pascal says the firmware he was showing could handle up to ten USB controllers and ten USB synths in addition to the five physical ports in each direction. That figure is a stress-tested maximum for the prototype, not a promise about a shipping product. He chose a Teensy 4.1 for its processing power and Arduino library ecosystem. The original five-port layout came from the kit used for the first prototype; adding more ports would increase the load on the processor.
The hardware also evolved through user feedback: a front-panel button for changing presets, status lights to show messages moving through the box, and a rackable enclosure less than one rack unit high. Pascal describes stacking four units in one rack unit as a path to 40 inputs and 40 outputs. These are design goals discussed in the interview, not a confirmed production configuration.
Live Lua rules instead of repeated firmware uploads
The main software decision is Lua scripting. Pascal tested other approaches and chose Lua because it is interpreted, relatively approachable, and can run on a microcontroller. The intent is to edit and test a rule while the box remains connected, instead of compiling firmware and uploading it after every code change.
In the web editor demo, the left side represents the box and its inputs and outputs. A connected controller sends MIDI into an input; by default, that input can route messages to selected outputs. The user can set default routing and filter message types such as clock, SysEx, Control Change, Note On/Off, and aftertouch. Rules can then be dragged into the signal path. A built-in MIDI Learn control can generate a condition from the channel, message type, and data value of a control the user moves.
Pascal demonstrates a “reverse CC” rule: a Control Change value is mapped in the opposite direction. The interface shows the incoming and outgoing values. The same rule can be limited by a condition—for example, only a particular CC on a specific MIDI channel—so other faders do not trigger it. Presets are Lua code, and the editor exposes variables and controls through annotations, such as a displayed bar. The stated aim is to let advanced users write and share presets while others can use community-made rules without coding.
The browser editor is built with JavaScript and runs a Lua interpreter; the box also runs a Lua interpreter. When connected over USB, the browser sends updates to the box using USB MIDI. The device IDs let the box recognize messages from the editor and keep them from being routed as ordinary performance data. In the demo, the box effectively passes its MIDI streams through to the browser while the editor controls the rule processing; after the user disconnects it, the configured box is intended to run on its own.
Pascal describes safeguards for scripts: syntax errors prevent a rule from running, and runtime errors are caught, surfaced with a message and line reference, and can light a red LED. He says a failing rule is isolated so it will not crash the whole box. This is an intended safety design explained during prototyping, not independent reliability testing.
A demonstrated Octatrack performance shortcut
The interview’s most concrete example uses an F.Fox controller and an Elektron Octatrack. Faders normally change track volumes. Buttons arm tracks for a coming break. Moving the crossfader then changes the volumes of all armed tracks together, using the reverse-CC transformation.
Pascal also demonstrates suppressing volume changes while the crossfader is at the break position. This lets him arm and prepare new tracks without sending their temporary fader movements to the Octatrack. Moving the crossfader back applies the prepared volumes for the next drop. The box coordinates messages from the controller and the Octatrack so one control can do more than either device supports by itself.
Limits, future requests, and prototype status
Viewers ask about timed CC ramps, clock generation, CV/Gate, and DMX lighting. Pascal is interested in automation that follows an incoming clock, but does not want the first product to become a clock source; generating and processing clock while interpreting Lua would add load. CV/Gate would require different voltage handling and conversion hardware, while DMX is another expansion direction. He frames those as possible separate products or later versions.
At the time of the interview, the box was still a prototype, not generally available. Pascal’s priority was reliability because the device would sit at the center of a performance rig; he wanted beta users before release and was considering crowdfunding after building a community. He says the scripting code would be open source from the outset, while the hardware’s licensing was undecided. The long path—from an internet kit and DIN jacks to a custom PCB, TRS compatibility, USB host, and a web editor—shows why the project is as much a software and usability effort as a routing box.
For a task-oriented explanation of the routing demonstrations, see the edited L1V3 Box session. This full conversation preserves the development decisions and audience questions around them.
