MOTOTON™
Organized time for an increasingly disorganized world.
Please proceed at an inappropriate tempo.

Browser-based rhythm pattern bank
Product Design

Launch MOTOTON™ ↗

"Rhythm is form cut into time" — Ezra Pound.

MOTOTON™ is organized time, fixed by design

I missed the rhythm boxes built into old electronic organs. Choose a pattern. Switch it on. Continue.

Contemporary tools can do considerably more. That was precisely the problem. MOTOTON™ reduces the idea again. A browser-based bank of over 150 fixed rhythmic objects — cycles, breaks, dances, ceremonial structures, asymmetric meters, machine rhythms and other ways of organizing when things happen. No generation. No blank sequencer. No hype.

The pattern already exists. The product was not designed to be a composition system. The patterns are deliberately fixed. A rhythm can be rotated, accelerated, remapped, or re-materialized without changing its underlying event structure. The object remains intact. Its identity does not necessarily survive.

Patterns can be exported as: MIDI / MULTITRACK MIDI / PCM WAV
These files are ready to use in external DAWs; MIDI carries the event structure. Multitrack MIDI preserves the individual rhythmic streams. WAV preserves the rendered Material state.

Choose a pattern. Alter its conditions.
Take the result somewhere else.

MOTOTON™ was developed as a three-day conversational prototyping sprint. The process moved continuously between research, interface design, rhythmic programming, testing, rejection, and specification.

Google AI Studio provided the implementation environment. The directing work remained largely the same as any other design process: define the problem → establish constraints → evaluate → remove → repeat

Tools/Credits:

Concept / Research / Creative Direction / Interface Direction:
Camilo Barria
Development Environment:
Google AI Studio / GitHub / Vercel
Research / Critique / Development Dialogue:
ChatGPT
Browser Audio
Tone.js

MOTOTON™ Rhythm Pattern Bank RPB-73 / Rhythms for sunshine pop and dark wave.
A clean interface inspired by the Ulm School of Design and Dieter Rams.

150+ RHYTHM PATTERN BANK
From vintage presets to cultural structures, from abstract studies to patterns inspired by the legendary Japanese labels ¥EN and Alpha Records. The library was developed through musical research, historical forms, and old rhythm-machine vocabularies.
The objective was not completeness but a mirror of global influences drawn from personal memories.

STRUCTURE WITHOUT EDITING
The Pattern Map exposes the internal event topology.
By design, it is observable, not editable. Timing, velocity, meter, and source streams remain part of the original rhythmic object. Intervention happens around the structure, not inside it.

ONE RHYTHM / DIFFERENT MATTER / VOLTAGE ← UNIT → PULSE
Material separates rhythmic structure from its audible surface. At the center, UNIT preserves the original percussion material.
Move toward VOLTAGE and the same events become unstable electronic behavior.
Move toward PULSE, and they collapse into impulses, sine fragments, and clicks.
MIDI remains unchanged. Same time. Different matter.

RATE & TEMPORAL SCALE 1/2X / 1X / 2X / 3X / 4X / 5X
BPM defines tempo. RATE changes the scale at which the rhythm is perceived.
At sufficient speed, distinctions between funk, ritual, cardiac activity, and malfunction become largely administrative.
This is considered acceptable.

Ableton 12 UI used for illustrative purposes only

TAKE IT ELSEWHERE
Patterns can be exported as: MIDI, MULTITRACK MIDI, and PCM WAV.
MIDI carries the event structure. Multitrack MIDI preserves the individual rhythmic streams.
WAV preserves the rendered Material state. 
Choose an object. Alter its conditions.
Take the result somewhere else.

THREE DAYS / ONE SMALL PROBLEM
Developed as a three-day conversational prototyping sprint, and progressively iterated towards a clinically clean and Ulm School-inspired design to steer it away from average results.
The process moved continuously between research, interface design, rhythmic programming, testing, rejection, and specification. Google AI Studio offered a fast divergent/convergent environment. Still, the execution largely followed the same steps as any other design process: define the problem, establish constraints, evaluate, remove, and repeat.