Maru builds instruments, effects and creative tools, and runs a research program underneath them. Both exist for the same reason: to get an idea out of a musician's head and into something they can hear, play and share. AI for Music is a set of principles for building AI toward that goal, and for deciding who gets a say in how it is built. We're joining.
What we do with AI
Most of the public conversation about AI in music is about generating finished songs. We find that a narrow question. The interesting problems start once you treat a model as a component in an instrument and ask what it has to do to earn its place there.
That is where our research lives. We model bronze gamelan bars from their measured mode ratios. We write voice-leading rules so generated chords move like a player's hands. We study how to generate a whole drum kit whose sounds belong together, because one plausible hit proves nothing about a role-complete kit. We build symbolic representations that keep timing, harmony and editability intact, because a note sequence that is merely plausible is useless in a session. We run benchmarks and listening studies that test musical usefulness instead of a single metric. And we study how a musician can guide an intelligent tool, inspect what it changed, recover their work and remain the author of the result.
Some of that already ships. A transformer writes drum patterns inside the browser tab, on your machine, and the part evolves when you change something instead of restarting. A drum machine renders its sounds with a latent diffusion model and interpolates between kits in the model's latent space, so the point between two kits is a sound of its own. The same TypeScript source compiles to VST3, CLAP and AU, and the native build is checked byte for byte against the browser render.
None of this changes our test for an instrument, whether it is acoustic, modeled or generated: does it leave you with more decisions, or fewer?
Who is involved
Roland and Universal Music Group launched AI for Music in 2024. Supporters now include Native Instruments, Focusrite, Splice, BandLab, Universal Audio, iZotope, Novation, Sequential, Oberheim, Eventide, Waves, Spitfire Audio, Output, ROLI, LANDR, Moises, SoundCloud and Bandcamp, alongside NAMM and MUTEK.
That covers most of the hardware and software a working producer uses in a day. Its members do not agree on everything. You can want the new instrument, worry about musicians' livelihoods, and demand to know what a model was trained on, all at once. Shared principles give those positions common ground to argue from.
The seven principles, in our words
Adapted from AI for Music:
- Music matters. Making and hearing it is part of a good life.
- People give music meaning. Music means something because people make it and listen to it.
- Technology can expand expression. The synthesizer, the sampler and the DAW each widened who gets to make music. Developed sustainably, AI can do the same.
- Creators deserve protection and recognition. Human-made work uniquely merits copyright. Using copyrighted material, or an artist's name, image, likeness or voice, requires authorization first and credit after.
- Trust needs transparency. Keep records, disclose where AI was involved, make contributors visible.
- Creators get a voice in development. From the first sketch through shipping.
- Help people create. Instruments, artist representation and music education all bring more people into music.
Support is voluntary and self-policed. The initiative's FAQ describes no enforcement process. We read that as an invitation to hold supporters, including us, to what they said. If a Maru tool falls short of a principle we signed, say so.
Where the principles meet the work
Principles on a website are cheap. They get interesting when they constrain an engineering decision.
Training data is the obvious one. Our kit-generation research is built on rights-clean data, and that choice is made before the first experiment because it cannot be retrofitted. The models we run come with different licenses, and one of them forbids commercial use. That difference decides what you can do with a recording made through the instrument, so the instrument has to say which model it runs where you can see it, and a render has to carry the model, preset and seed that produced it.
Authorship is the other. When an artist brings us a recording process or an effect chain, it becomes a plugin released together, with shared revenue and their name on it. When an agent helps shape a sound in Studio, the musician's direction stays in charge and every change is audible before it is accepted. The research question behind both is the same: how does a person guide a capable tool and still end up with something that is theirs?
So the questions we put to any tool, ours included, are concrete. What does it open up? Which decisions does it hand back to the musician? Whose work made it possible, and does the tool say so?
The answers depend on who is asking. A teacher wants a student to hear four voicings of the same chord. A performer wants an instrument that responds to a gesture their body can make. A producer wants a texture they have never heard so they can sample it and mangle it. Same principles, three different tools.
What comes next
We want tools that are easy to start with and still rewarding after years of use. Acoustic playing, electronic performance, sampling, code, live coding, and whatever combination you invent next. We build for all of them.
Formal supporter enrollment is still ahead of us. First we are reviewing our own models and their source material against the principles above. Signing before checking would mean nothing.
