Before Reliq could become a sequencer, a matrix mixer, a control surface, or whatever else we were imagining back then, it first had to do something much more basic.
It had to keep time.
This sounds almost too simple to say. Of course a sequencer has to keep time and a clock has to be stable. But this became one of the first real obsessions behind Reliq, and in a way one of the first places where the instrument started to define itself.
You can have all the generative features in the world. You can have randomization, probability, Euclidean patterns, all sorts of beautiful musical ideas running in parallel. But if the beat is not really on the beat, the result does not feel right. It can be clever or complex and impressive, but it does not feel like the machine is responding back to you.
And for the kind of electronic music that shaped us, this is where everything starts.
Around 2016 and 2017, most of us were studying electronic music composition or sonology at the Royal Conservatory in The Hague. We were all from different places, with different backgrounds and obsessions, and a lot of energy for exploring electronic music in a very open way.
At the same time, we were also just trying to survive all the normal things. Moving to a new country, school, money, jobs, trying to understand what happens after studies, trying to build a life around music without knowing exactly what that life is supposed to look like. But through all that, we were meeting almost every Tuesday and Friday, sometimes even more often, to make music together.
And these sessions were not very stable, in the best and worst sense of the word.
One week someone would bring custom software. Another week someone would bring some weird hardware idea. Michele (who later ended up being our electronics master) had this very impressive setup at some point using muscle tension to control feedback loops or granulators. There were joysticks, drum machines, very old synthesizers, Eurorack systems, laptops, controllers, small and big boxes, things that were not meant to talk to each other but we really wanted them to.
Every session could be completely different from the previous one. Even if there was a performance coming a few days later, we could still spend the whole week building some new system or writing some new software patch because the excitement of trying something was bigger than the comfort of having a “stable” setup.
It was one of the most inspiring, and complicated, times.
But also, of course, it was an absolute mess.
A lot of the time that was supposed to be music became setup. Connecting and disconnecting things. Finding the one cable that works. Deciding if the computer or a hardware sequencer should be the master clock. If the modular should receive CV clock or MIDI-to-CV.
Trying to understand why one drum machine was a little bit late compared to the CV gear. Rebooting the computer. Rebooting the interface. Turning everything on in a different order because apparently that mattered.
And at some point we started arguing about something that was not only technical anymore.
Were we really making music there? Is this how music making is supposed to look and feel?
Is routing part of the music? Is mixing before composition, during composition, or after it? Is the way you patch a Eurorack system a technical preparation, or is it already part of the piece? If you change the order of post effects, or the way one machine clocks another machine, is that just setup, or is that already music?
The more we played together, the more we became convinced that all these decisions were part of the music. Even connecting a cable, or moving one encoder, or choosing which machine follows which clock, could completely change the music.
But the problem was that these parts almost never felt like music.
They felt like administration and troubleshooting. Like the thing you had to do before you could finally make music.
A lot of Reliq came from that contradiction. Not from one single idea, but from all these sessions and the feeling that the technical parts of an electronic setup were deeply musical, while the actual experience of doing them was often not musical at all.
And one of the first places where this became painfully obvious was clocking.
We tried so many clocking setups during those years. Dedicated hardware clocks (that was before our friends from Sim'n Tonic had made the Nome). Sequencers as master clocks. Computers as master clocks. Software tricks. MIDI clocks. CV clocks. MIDI-to-CV converters. Audio pulses. Any combination that seemed like it could make a hybrid setup behave.
Sometimes we wanted the Eurorack system, a drum machine, a computer, and some MIDI synths to all play together. On paper this sounds very normal. In practice, one device would be slightly delayed. Another one would not accept the kind of clock you wanted to send. Another one had great timing but not enough MIDI ports.
So we would make these strange fragile solutions. If the clock comes from this box, and then this other box distributes it, and then this one device is delayed by this amount, and this one cable goes here and not there, then everything works.
Until you change one thing. And then everything falls apart.
For a performance this is a terrible feeling.
Because loose timing is one thing. Sometimes loose can even be musical. But unpredictable timing is different, it gives you anxiety.
At first we thought this was strange. As users, when a device says it synchronizes to your computer or to another piece of gear, you imagine this is a solved problem. It feels like synchronization should be a simple and standardized task. One machine sends time, the other machine follows time, and everyone is happy.
But almost none of the gear we tried really worked like that once the setup became big enough.
Some very expensive sequencers had impressive clocks. Some dedicated clocks were much better than others. Other devices were really solid as long as they were the center of the setup. But when, for example, we brought a computer into the game, everything became more loose, and unpredictable.
It took some time but eventually we started understanding why.
MIDI is beautiful. It opened the world for electronic musicians. We are still using it in 2026 because it is simple, robust, and almost everything understands it. But it was created in the early 1980s, for a very different world of electronic instruments.
A standard MIDI clock is not really “tempo” in the way it is easy to imagine. It is pulses. Twenty-four pulses per quarter note. One machine claps, and the other machine has to follow the claps.
I found an email recently that I sent to Giuliano [Editor’s note: our main software wizard and dad jokes expert] in early 2020, before Reliq was even an idea. The first line says:
“MIDI clocks are an ancient art of fighting with cables, OS and software in order to not synchronise multiple devices together.”
Reading it now, it is funny because it is half technical note, half a rant from spending too many hours doing measurements.
The email goes on to describe MIDI clock as an automated tap-tempo system, which is still one of the simplest ways I can explain it. The master sends timing clock messages — MIDI status byte 248, or 0xF8 — at 24 pulses per quarter note. In 4/4, that becomes 96 pulses per bar. The follower receives those pulses, measures the time between them, and tries to infer the tempo.
One musician trying to follow another musician who is clapping their hands twenty-four times per quarter note. If one clap is a bit early, the follower has to decide: was this a real tempo change, or was it just a mistake? If the next clap is a bit late, again the follower has to decide. And it has to keep deciding all the time, while the music is happening.
This seemed a little primitive to start with. But then you think about how much we ask from modern electronic setups. There is a clock, but then we also put notes, CC messages, automation, modulation, polyphony, transport, everything on the same pipe, and the pipe has a limit.
Classic DIN MIDI runs at 31.25 kbit/s. A normal three-byte MIDI message takes roughly 0.96 ms to transmit. That sounds small, and in many situations it is completely fine. But the important part is that MIDI is serial.
If ten things need to happen at the same musical instant, they do not actually leave the cable at the same instant. They line up.
On the piano roll, the kick, snare, bass note, chord, CC automation, transport message, and clock pulse may all be on the grid.
On the wire, they are in a queue.
Add all of it and they will be sharing the same limited serial pipe. A clock pulse might arrive 10 or 20 ms later than what you would expect. Not because something is broken, necessarily, but this is the protocol doing what it can do.
So the first lesson was that if you care about timing, clock is not another message floating inside a busy stream.
Of course, this is easier said than done. And then the computer enters the room and makes the problem a bit more complex.
Computers are amazing because they can do so many things. They create the illusion that everything is happening at the same time. You can run a DAW, plugins, graphics, USB devices, MIDI interfaces, WiFi, background processes, all of this in one machine, and most of the time it feels like one continuous thing.
But anyone who uses a computer also knows the other side of this. Sometimes you click something and it opens instantly. Sometimes you click something and it takes five seconds. Sometimes you connect a printer and the whole computer goes for a walk.
This also explains why you can connect a DAW to some external device and the BPM display does not sit still. It says 120, then 120.3, then 119.9, then 120.5. Nothing dramatic maybe, but enough to feel that the system is always calculating and always slightly unsure.
This is where it would be easy to write the simple version: computers are bad at timing. But that is not really what we thought, and not really fair.
Some of us were already working in tech. We had experience with software, audio systems, kernels, scheduling, and the usual pain of trying to make digital systems behave in real time. We knew there were reasons for what we were seeing.
In a way, that made it more frustrating.
We could understand why the stack was fighting us, but as musicians the request still felt simple: when I press play, everyone should agree where beat one is.
A general-purpose computer is an amazing machine exactly because it is not designed to do only one thing. It runs the operating system, the DAW, the audio engine, plugins, graphics, USB devices, MIDI drivers, disk access, background processes, networking, window management, and a hundred other things.
But at the CPU level, a lot of this is scheduling. Threads compete for time. Interrupts happen. Buffers fill and empty. Drivers wake up. The audio thread gets priority, hopefully. The MIDI thread may not get the same treatment. A plugin can spike. The graphics system can interrupt. USB packets move through another layer. The scheduler tries to be fair, or responsive, or power efficient, or real-time enough, depending on the system and configuration.
None of this is strange. This is what computers do.
But music, especially rhythmic music, does not care that the system had other things to do. It wants the event to happen at the point where the music says it should happen.
This is why many DAWs prefer to be the master clock. It makes sense. A DAW has its own audio engine, its own buffers and plugin delay compensation, and it wants to organize the world around that. Following an external clock means constantly interpreting incoming pulses, smoothing tempo, adjusting transport, dealing with jitter, and keeping audio stable at the same time.
Many DAWs can follow external clock, of course, but anyone who has tried to make a serious hybrid setup this way knows the feeling. Sometimes it is fine and usable. Sometimes it is not.
This is not because computers are not good music tools.
It is because accurate musical time across protocols, devices, buffers, drivers, and operating systems is a hard problem.
Years later, when we started working on the first version of Reliq, this was already deep in our minds.
At the beginning, Reliq was not supposed to become a product in the way it is today. It was a prototype for us. Something we wanted in our own studios, to jam together and bring all these different parts of our setups into a more playable relationship.
But even in that early form, we already knew some of the shape of it.
We knew we wanted many tracks. We knew we wanted MIDI. We knew we wanted CV. We knew we wanted gates and clocks, a matrix. We wanted the instrument to sit between different worlds: modular, MIDI hardware, analog routing, mixing, DAWs, performance, composition.
And this immediately made the clock problem unavoidable again.
What is the point of having 32 CV outs, 16 gate and clock outs, multiple MIDI outputs, USB MIDI, USB host, and all of this connectivity, if they do not agree on time?
If MIDI output one hits here, and gate output sixteen hits two or three milliseconds later, the analog clock is somewhere else, then the number of connections does not matter. It is not an instrument anymore. It is just a collection of outputs.
From the very beginning, timing was not something we could add later. It had to be figured out so it could shape the architecture.
This created one of the central engineering tensions behind Reliq: we needed power, but we also needed deterministic time.
A very time-critical architecture can be extremely precise, but it usually comes with limited memory and limited flexibility. A more powerful system gives you much more room for features, UI, storage, connectivity, graphics, big projects, future development, and all the things that eventually became the instrument. But it can be much harder to make it behave deterministically.
This is one of the reasons why many electronic instruments eventually need a new hardware generation. At some point the architecture that made sense at the beginning runs out of space. You run out of memory, or processing headroom, or timing guarantees, and there is not much you can do besides making new hardware.
We were very aware of this. So every early decision had clocking somewhere inside it.
Even when we were thinking about processing, UI, outputs, or future features, there was always this question underneath: Can this still keep time?
The full processing architecture of Reliq deserves its own article, because it became a very important part of the whole instrument. But for this story, the important part is that the clock was not a small subsystem. It is a core foundation.
We went through several prototypes and proof-of-concepts. Some were close, but not close enough. Some others worked in one situation and failed in another or looked good until we imagined adding a computer, or more outputs, more complex sequencing, and then the whole thing started feeling fragile again.
Eventually we had to approach it layer by layer.
The first layer was the internal clock. Before Reliq could follow anything else, talk to a DAW, or become the center of a hybrid setup, it had to agree with itself. All of its own outputs had to share the same sense of time. MIDI, gates, clock outputs, CV-related events, sequencer steps, internal modulation, all of this had to come from one stable musical timeline.
One of the core decisions we made was to use a much higher internal clock resolution than standard MIDI clock.
Standard MIDI clock is 24 PPQN.
Reliq’s internal clock architecture runs at 768 PPQN. That is 32 times the resolution of standard MIDI clock.
At 120 BPM, a standard 24 PPQN MIDI clock pulse arrives every 20.833 ms. At 768 PPQN, Reliq’s internal tick is around 0.651 ms.
That was a big difference. It does not mean every musical event should become robotic or that all timing should be quantized without feel. It means the instrument has a much finer internal grid from which to schedule events, offsets, divisions, clock outputs, gates and anything else. It gives the system room to place things more precisely before they are converted into the different languages of the outside world.
But it also creates a new problem.
If your internal clock is much higher resolution than the clock you receive from outside, following external clock becomes harder. An incoming MIDI clock pulse every 20.8 ms at 120 BPM has to be interpreted into a timeline that internally moves every 0.65 ms.
If the incoming pulses are slightly uneven, you have to decide how much of that unevenness is real tempo movement and how much is jitter.
If you react too fast, the whole system becomes nervous. If you smooth too much, the system becomes late or unresponsive. You ignore too much, and you are no longer really following.
This is a boring part of clocking that becomes very musical very quickly.
So we measured. A lot.
And the more we measured, the more we realized that measuring a clock is a small art by itself.
It is easy to put a device on a logic analyzer or an oscilloscope, look at the pulse train, and get some numbers back. But those numbers only become useful when you know what you are actually looking for.
At first, the temptation is to look for the worst pulse. We did this too. Some of our favorite machines showed peaks that disappointed us at first. But then we started understanding the character of those peaks.
Going back to the clapping metaphor: if someone is clapping steadily and one clap arrives obviously late, the follower can understand that as a mistake. It is a visible inconsistency. The next claps return to the center, and the tempo can be smoothed. But if every clap is slightly early or slightly late, all the time, the follower has to constantly chase the timing. So the question became less about finding the scariest single number, and more about understanding the behavior of the clock as a stream.
Does the main pulse stream stay centered? Does it drift over time? Does it behave similarly at different tempos? Stay stable when the sequencer is actually playing notes, sending CC, triggering gates, changing patterns, and reacting to the user?
That last part became especially important for us.
A sequencer is not used as a silent clock generator. It is used while making music. So a clock that looks great when every track is muted, but changes character once notes and modulation enter the system, was not good enough for what we wanted Reliq to be.
Reliq also made this problem more demanding than usual. We were not building just a clock. We were building an instrument with many tracks, polyphony, automation, MIDI, gates, CV, clock outputs, a matrix system, internal processes, and eventually DAW integration. The amount of musical data moving through the system could become very large. If the clock became late or unstable when the machine was busy, then the architecture was wrong.
So the measurement process helped us define the clock that Reliq needs. Stay on the grid for pulses, avoid long-term drift, remain stable under musical load, behave consistently across useful tempos, and survive development without new features quietly damaging the timing foundation.
It took a while, but that first stable clock measurement was a big moment for us — even before Reliq took its current form.
Not because Reliq was finished. It was absolutely not finished. We still had so much to solve. Different PPQN settings on analog outputs. External clock following without big deviations. More robust synchronization. Behavior under different loads. Transport handling. Reset behavior. Clock divisions. And, later, the much bigger mountain of tight DAW synchronization, which deserves its own full story.
But that moment told us something important. We had something to build on.
This mattered a lot, because the clock is one of those parts of an instrument that nobody notices when it works. You do not look at a feature list and feel excited because it says “the kick and the hat arrive together.” You just expect that, and it should be invisible.
But if it does not work, everything becomes about the clock. You start thinking about the setup instead of the music. This is what we wanted Reliq to remove from the music-making experience.
Not because the technical setup is not musical. We truly believe the opposite. Routing, clocking, mixing, modulation etc all of these things are musical. But they should feel like musical actions, not like administrative anxiety.
This is why the clock came first.
Long before the feature set became what it is today, before the big display, the full matrix system, or the OS roadmap became part of the story, we spent months just trying to understand how time should live inside the instrument.
And before that, we had spent years being frustrated by clocking in our own setups, in rehearsals, in studios, in live situations, in all the places where a machine saying “sync” did not always mean that the music felt synchronized.
Even now, clocking is one of the parts of Reliq we still measure before each update.
We keep oscilloscope captures. We compare behavior. We make sure new firmware work does not quietly damage the timing foundation. And still today, some of the longest-running features in development, like per-track MIDI latency compensation or U-SYNC for Windows, are very much clocking problems at their core.
During recent Rlx 1.7.0 development, we measured Reliq once again against several devices that represented different real-world clock architectures: a compact hardware sequencer, a standalone sampler/sequencer workstation, and the most exclusive dedicated hardware sequencer we had access to, which had been our personal timing benchmark for years.
We are not naming them here because the point is not to turn this into a competition. These were machines we had used, respected, and trusted.
All measurements in the graph below, except the standalone sampler/sequencer workstation, were performed at 135 BPM under equivalent MIDI note and CC load. The workstation is shown clock-only, because even without additional load it already behaved like a different class of clock source.
The important result is not only the graph itself. It is that the clock behaves the way we had designed it to behave.
The main body of the pulse stream stays extremely close to the grid. The average movement stays very low. The long-term tempo stays stable. And adding musical load does not change the behavior of the clock.
Because everything else sits on top of it.
The sequencer, the matrix, the MIDI outputs, the gates, the CVs, the DAW integration, the future features, all of it depends on this first agreement:
Time has to be solid.
And possibly this is the first real chapter of Reliq. Not the feature list, the product announcement, the campaign or the final hardware.
Just trying to make too many machines play together, slowly realizing that before you can build a better electronic instrument, you first have to build a better sense of time.