If the first foundation of Reliq was time, the second was architecture.
Not architecture as a block diagram, a Bill of Materials, or a list of processors and chips, but architecture as a musical question: how do you make many different worlds behave like one instrument?
This was one of the problems we kept running into long before Reliq existed. A studio or live setup could be incredibly powerful, but also deeply fragmented. A modular system had one logic. A MIDI sequencer had another. A DAW had another. Analog routing, CV, gates, audio, controllers, plugins, clocks, mixers, all of them could be part of the same piece of music, but they rarely felt like one coherent body.
The first article in this series was about time, because timing was the first invisible agreement Reliq needed to make.
This second part is about the machine that had to exist around that clock.
By early 2020, we had already collected a large drawer of ideas.
Some of them came from performances. Some came from jams. Others came from long discussions that started as technical arguments and slowly turned into something more philosophical. We knew what was frustrating us. The feeling of electronic music becoming more like technical administration than performance. The pain of setups that depended too much on cables, clock choices, routing diagrams, workarounds, and patience.
We also believed deeply that many of these "technical" things were actually how music came to be.
Routing was not just setup. Mixing was not something that happened only before a performance or after a recording. Clocking was not just a utility. Connections, levels, modulation, CV, MIDI, software, hardware, and post effects were all part of the musical decision-making.
The problem was that they rarely felt performative.
They felt like the work you had to do before the music could start.
So we had this growing feeling that something was missing. Not another small box that solved one corner of the problem or another controller for one software environment. Not even another sequencer that assumed the rest of the studio would somehow organize itself around it.
We wanted something that could sit in the middle of many worlds and make them feel like a single instrument.
Then the world suddenly stopped.
In early 2020, the COVID pandemic started, and like for many people, a lot of our plans disappeared almost overnight. Gigs were cancelled or postponed indefinitely. Performances that felt close suddenly became abstract. Everything became uncertain. But strangely, this also meant we had more time than usual to meet, talk, and think through these ideas.
We were still making music, but the discussions became longer and more practical.
At some point, the question became quite simple: Maybe we should try to build this.
At the beginning, this was not a plan to start a company, or a product roadmap. It was not even "let's build Reliq." It was more naive than that, and maybe because of this, more tangible. We had problems in our own setups. We had ideas about how we wanted music making to feel. Some of us had experience with hardware design, circuit design, software, embedded systems, audio, and lower-level development. So we thought, okay, maybe we can solve this for ourselves.
How hard can it be?
In retrospect, of course, much, much harder than we could ever have imagined.
But that was a beginning.
We put some money together, started buying parts, and began testing the separate ideas one by one. At that stage, everything was intentionally fragmented. We did not try to build the full instrument immediately. That would have been impossible. Instead, we separated the problem into pieces.
There was a prototype for clocking. Another for sequencing. Another for the analog matrix. Another for display experiments. Another for reading controls.
At the time, this separation made sense. We needed to know whether each idea was even possible. Could we build a clock stable enough to become the foundation? An analog matrix that could switch and route signals musically? An interface that was dense enough to control a complex setup but still playable? Could we drive a display large enough and clear enough to show the state of the instrument without turning everything into menu diving?
Every subsystem had its own small world.
The clock prototype had its own hardware and its own timing logic. The sequencer prototype ran on its own processor. The matrix experiments had their own analog circuitry. The user interface started with MIDI controllers and pad-based controllers literally taped together to simulate a larger grid. Later we started looking for off-the-shelf components that could approximate the kind of interface we had in mind.
This was useful because it let us move fast. It was also very far away from having an instrument.
Five separate prototypes do not magically become one musical workflow. Each of them can work in isolation and still fail completely when connected to the others. In fact, this became one of the main realizations of that period.
You can solve five problems separately and still not have a solution.
The harder question was hardware architecture.
If we ever wanted all of this to become one instrument, what kind of hardware was actually needed underneath? What processing architecture could run a detailed interface, a sequencer, a clock, a matrix, hundreds of user inputs, MIDI, CV, gates, storage, future features, and still feel like one coherent musical object?
We tested different processors, different development boards, different displays, different analog switching approaches, and different interface ideas. Some processors were very good at graphics and higher-level tasks. They had a lot of memory, could run complex software, and could potentially handle files, networking, display rendering, and many of the modern things we wanted Reliq to eventually have.
On paper, it looked like exactly what we wanted.
Not a tiny screen with a few cryptic abbreviations, and not a workflow where you need to remember too many hidden states or press through too many layers just to understand where you are.
We wanted the instrument to show what was happening with clarity.
The screen was not just a beautiful object. It was part of how the complexity would become playable.
But the more we tested application-class processors, the more we saw the other side.
They were powerful, but not naturally deterministic. They could run displays, storage, and higher-level systems, but that did not mean they should be responsible for a gate firing exactly at the right time or a MIDI event landing where the music expects it. These processors are designed to do many things very well. Their power comes partly from that flexibility: caches, memory systems, operating systems, graphics pipelines, and in many cases out-of-order execution that allows the processor to reorganize work internally for efficiency.
All of that is useful.
But musical time does not care how efficient the processor was being internally. If a gate is late, it is late. If the system was busy drawing something on the screen when a musical event needed to happen, the music will not forgive the explanation.
Then there were real-time processors, or MCUs.
These are much closer to what you find in many musical instruments. They are usually cheaper, more predictable, closer to the hardware, and much better for time-critical tasks. If you want to toggle a gate, scan inputs, generate a clock, schedule a low-level event, or control something with very precise timing, this world makes a lot of sense.
But MCUs come with their own limitations.
Memory is limited. Storage is limited. Graphics are limited. Complex file systems are harder. Networking is harder. Future expansion is harder.
We knew from our own experience as users how frustrating these limits could become.
We had many devices we loved that eventually reached their ceiling. Not because they were badly designed, but because the architecture had a fixed amount of memory, processing headroom, storage, or UI capacity. At some point a new feature becomes impossible. At some point a new workflow needs new hardware. As a musician, you understand why this happens, but it can still feel strange to invest years of muscle memory and a significant part of your music budget into something that cannot grow much further.
We did not want Reliq to hit that wall in the same way.
At the same time, we could not simply choose the powerful route and ignore timing.
This also explained a divide we had seen in gear for years. Some devices had pretty solid timing, but very limited pattern length, storage, or project structure. Others had bigger screens, samples, plugins, and much deeper features, but their timing could feel less stable, and sometimes they needed minutes just to boot.
We started understanding why this divide existed, and it became clear that Reliq could not sit comfortably in either category.
It needed room to grow, but also deterministic time. It needed a big interface and deep project structure, but also gates, clocks, MIDI, CV, and user actions that could happen without the system becoming nervous. It needed a modern brain, but also reflexes.
Then there was the analog side.
This was another problem that looked more solved from the outside than it actually was.
Digital systems switch very fast. Processors, memory, displays, USB, wireless modules, graphics systems, all of these things create high-frequency activity. In many devices this is completely fine. But when you also have analog audio, CV, or sensitive switching circuitry in the same instrument, the digital world can leak into the analog world in ugly ways.
As musicians, we had heard this countless times without necessarily knowing the source. A USB-powered device plugged into a computer, then connected to a modular system or audio path, suddenly produces a high-pitched whine or switching noise. Sometimes a splitter or isolator helps. Sometimes different grounding helps. Sometimes the noise gets lower but never fully disappears.
For us, this was a core part of the problem we were trying to ease for ourselves.
The analog matrix was not a standalone unit or an accessory. It was one of the core ideas of the instrument.
If the digital side was going to pollute the analog side, then we had failed before the musical idea even had a chance.
So the architecture problem became more layered.
We needed a powerful processor for graphics, storage, files, future features, and the high-level parts of the system. We needed real-time behavior for timing, gates, MIDI, clock, and musical events. We needed analog switching and analog control to be isolated enough that the digital activity would not leak into the musical signal path. We needed hundreds of buttons and encoders to respond quickly, without user input disturbing clocking, display, or the analog side.
All of this had to feel like one instrument.
For a while, the whole thing became absurd.
At one stage we had multiple processors, multiple boards, multiple prototypes, and more custom cables than we thought we would make in a lifetime. The screen system was separate. The sequencer logic was separate. The analog matrix was separate. The clock and gate system was separate. Even the interface scanning was separate. Then all of these things had to be connected somehow so we could test if the musical idea made any sense.
Eventually, we mounted a large part of this Frankenstein prototype onto a foldable keyboard stand.
On the top side, we had the beginning of a user interface: buttons, controllers, off-the-shelf parts, laser-cut pieces, 3D-printed standoffs, whatever we could use to make the thing playable enough to test.
Underneath, there was the other reality: processors, boards, IO, power, and hundreds of cables.
This created what Michele started calling "car mechanic mode."
Every time something stopped working, someone had to go underneath the keyboard stand with a flashlight, check a cable, solder something, replace a connection, or figure out which part of the monster had decided to stop talking to the rest.
It was funny. It was also slightly depressing.
We were trying to build an instrument that would remove technical administration from the music-making process, and somehow we had built the most administratively demanding setup we had ever touched.
But it also worked just enough to keep us going.
For the first time, we could test pieces of the thing we had been discussing for years. We could switch analog signals while sequencing, send CV and MIDI from the same larger system, and see how a performance gesture in one part of the interface could affect another part of the setup. It was fragile, ugly, and very far from an instrument, but some moments felt genuinely new.
That was enough to convince us that the potential was there.
The problem was that the prototype itself had become a mirror of the problem we were trying to solve. It proved the musical idea, but it also showed us exactly what Reliq could not become.
Outside the box, our musical setups were fragmented. Modular, MIDI hardware, DAWs, software instruments, analog routing, clocks, controllers, all speaking different languages and struggling to behave as one system.
Inside the box, the prototype was fragmented too. Application processors, real-time processors, analog switching, display systems, user input, memory, storage, and timing were all living in separate worlds.
At some point, this became the real breakthrough.
The processing architecture was not a separate engineering problem from the musical problem. It was the same problem, reduced to a smaller physical scale but a larger technical one.
We wanted musical setups to feel unified. So the inside of the instrument also had to become unified.
But we could not pretend that everything was the same.
A DAW and a modular system are different worlds. MIDI is not CV. Analog audio has very little to do with a file system. A real-time processor is not an application-class processor. A display engine has very little to do with a MIDI clock generator. These things have different strengths, different weaknesses, different timing expectations, and different failure modes.
Trying to force all of them into one generic processing world would have meant compromising the instrument in one direction or another.
So, instead of asking which single processor should run Reliq, we started asking what each part of the instrument needed to be excellent at.
One domain needed to protect musical time. Another needed to handle graphics, storage, project management, updates, and high-level logic. Another needed to control the analog matrix while staying isolated from digital noise. Another to read a very large number of user inputs quickly and reliably.
And all of these parts needed to communicate as if they were one thing.
This was the first architecture idea that started making sense.
Not many separate devices or a collection of boards glued together. One custom system, with different processing domains inside it, each doing what it was good at while sharing enough information to behave like one instrument.
After almost a year of fragmented prototypes and approaching the problem from different directions, we still had little more than proof that the musical idea had potential and a hardware specification that looked more like a shopping list than a proper engineering brief.
While writing this article, I found an old note describing what the hardware needed to do. It is funny to read now because the list looks relatively simple, while almost every line contains a technical contradiction:
- Drive a 1920 × 515 display at up to 60 Hz.
- Scan all 303 buttons and 18 encoders continuously at 1 kHz or higher.
- Maintain average clock cycle-to-cycle jitter below 40 µs.
- Keep gates, CV, DIN MIDI, and USB MIDI events aligned with sub-millisecond accuracy across all output domains.
- Provide zero-copy shared-memory paths, with direct memory access where required, so musical actions, outputs, and UI elements could exchange data without unnecessary copying or unpredictable delays.
- Run the initially planned feature set using less than 20% of the available processing and memory resources, leaving substantial room for future development.
- Run the sequencer internally at 768 PPQN while supporting what we optimistically described as "perceptually unlimited sequencing length."
- Keep the analog and digital signal-generation domains isolated, with differential signaling where required for data.
It was quite a list. But after months of separate experiments, it was also the first time we had something concrete to build towards.
As a first step, this led us into shared memory regions, direct communication paths, and a lot of research into how different processing domains could exchange information without turning every message into another slow or fragile protocol.
The basic idea sounds simple: two or more processing units need to access a shared region of physical memory and agree on what the data means.
In practice, it was not simple at all.
You need rules. You need ownership. You need safety. You need to know who writes, who reads, when something is valid, when something has changed, how to avoid race conditions, and how to make sure one part of the system does not accidentally block another part. The real-time side has to stay real-time, while the high-level side still gives it musical information. The display has to react quickly without stealing timing. User input has to feel immediate without creating noise in the clock.
This was not a common path, and at the time there was not a huge amount of practical documentation for the exact kind of system we were trying to build. There were datasheets, reference manuals, research papers, examples that almost applied but not fully, and then there were errata.
Errata became a big part of our life.
For anyone lucky enough not to know this word: errata is "a list of errors in a printed work discovered after printing and shown with corrections" [Source: Merriam-Webster].
Errata is where hardware manufacturers document all the weird things that do not quite work as expected in the silicon. Sometimes your code is wrong. Sometimes your board is wrong. Sometimes the chip has a behavior that is technically known, but buried in a document of hundreds of pages.
So you spend days chasing a bug, and eventually you discover that the hardware itself has a condition, exception, or limitation that only appears when a few very specific things happen together.
This was the kind of development phase where progress did not always look like progress.
Sometimes progress was discovering that a bug was not in the code. Sometimes it was accepting that the bug was very much in the code. Sometimes it was realizing that a board had been assembled incorrectly. And sometimes it was realizing that the idea was correct, but the first implementation was not.
Slowly, the blueprint became a bit clearer.
The application-class domain would handle the screen, files, project management, updates, and future expansion. Time-critical work such as clocking, MIDI, gates, and CV timing belonged to the real-time domain, while the analog matrix required its own carefully isolated control environment. A separate input domain could scan hundreds of buttons and encoders without disturbing either the display or musical timing.
These domains had to become parts of one custom brain controlling one instrument.
This is where the architecture started to resemble the musical idea again. Multiple technologies, each with its own strengths, behaving as one musical system.
Of course, there is a reason this kind of architecture is not the most common approach.
It is expensive in almost every possible way.
The design cost comes from defining every domain, boundary, shared memory region, and communication path carefully enough that the instrument can grow without collapsing later.
The hardware itself requires more processors, memory, power domains, isolation, routing, PCB layers, differential lines, and attention to signal integrity.
Firmware becomes a small society of programs that must agree on what the instrument is doing.
Manufacturing creates another problem entirely. Not every PCB factory can build this kind of board reliably. Most assembly houses we were aware of were not comfortable with this density and complexity. In some of the early system-on-module prototypes, we spent months trying to understand whether the problem was in our design, our code, or the manufacturing itself. Eventually, in at least one case, the issue came from the fabrication or assembly process, not from the architecture.
That was painful, but also useful.
Because after enough revisions, enough waiting, enough testing, and enough back and forth, we finally had a working system-on-module in our hands: the first real version of Reliq's own brain.
That was quite a moment. For the first time, the shopping list was no longer theoretical. We could test it.
The display could run at its target refresh rate. How you reliably drive a display like this, and what "up to 60 Hz" really means in practice, is another story that probably deserves its own article. All 303 buttons and 18 encoders could be scanned above 1 kHz without disturbing the time-critical domains. The 768 PPQN sequencer, zero-copy communication paths, output alignment, and isolation boundaries were no longer diagrams or assumptions. They had become measurable properties of the hardware.
Slowly, we validated each requirement. This did not prove that Reliq was finished. Not even close. It just proved that the hardware architecture was capable of becoming the instrument we had imagined.
We had a system where different processing worlds could coexist. The high-level side could handle the screen, files, updates, and future growth. The real-time side could protect the musical timing. The analog side could stay isolated. The user interface could be responsive. And all of it could start behaving less like a pile of prototypes and more like one instrument.
This was the point where Reliq stopped being only a collection of ideas and started becoming an instrument.
We used to think of architecture as an invisible technical choice. In many ways it is. You do not see it directly when you look at the front panel. You do not press a button and think about shared memory or isolated processing domains.
But you feel its consequences.
The screen can show deep state without making the clock nervous. The matrix can switch without digital activity leaking into the analog path. Input gestures remain immediate while musical timing stays protected. And the instrument can continue growing through software without needing to become an entirely new piece of hardware every time the ideas expand.
Most of all, we started feeling it when many different musical worlds start behaving as if they belong to the same instrument.
That was always the ambition.
Reliq was never meant to be one generic processor forcing everything into one language. But it also could not remain a collection of separate boards talking through fragile connections. It needed its own brain: a custom architecture with specialized domains inside it, each respecting the world it served, coordinated tightly enough that we no longer had to think about the boundaries while making music.
In the end, the architecture was a small version of the musical problem. So before Reliq could unify a studio or a live setup, it first had to unify itself.