Using an external clock

Do any of you use an external clock in your squarp pyramid setup? The pyramid has clock hiccups cause me problems and so i’m exploring how I might use some super sharp external clock like https://www.e-rm.de/midiclock/

I know the pyramid will sync to an external clock, but I don’t know if it passes the clock signal through like a passive midi through to the connected devices or if the squarp just grabs the tempo and generates it’s own clock out the pryamids midi ports.

Has anyone played with this idea before? I’d love your thoughts.

Looking at the manual it doesn’t specify, but what little I know of the MIDI spec would lead me to believe the Pyramid passes the original clock signal on to other devices… I believe this is how it works with MIDI THRU because as I’ve been told THRU is simply a cloned hardware output that sends everything through unchanged.

I will say this… one of the e-rm devices is on my extended wishlist… I’ve heard a lot of good things about the devices and the premium one has the ability to offset any signal or [halve/double on the fly EDIT: it may not have this feature… I thought it did…]… As midi clock is the main selling point I’d like to assume that the clock from their devices is pretty rock solid…

These are just my presumptions though… for a definite answer emailing them through the contact form is likely your best bet.

yes, it will send the clock/transport straight thru without using the pyramids clock.

test i tried:
a) octatrack clock/transport → midi in pyramid
b) pyramid → all clock sync/outputs options off
c) pyramid port B → set to THRU → hermod

start clock on octatrack,
pyramid remains stopped
hermod starts transport/clock

changing tempo on octatrack, updates hermod … but pyramid (as expect) remains on its internal tempo.

so yes works as you would expect.


technically, I suspect this is a SOFT thru, which is common on digital devices.
this means the message stream is read digitially and then re-written to the output port.
usually/often this will be done without any interpretation, so can be very quick.
but as above, Id check with Squarp via the contact form.

generally, I’d not expect any latency, but you will only know when you try…
perhaps if you want the tightest possible sync… id consider a midi thru box.

1 Like

Awesome - thanks for this; this is kind of what I wanted to hear. I don’t need a ‘tight’ sync so much so as I’m having issues with the ‘SYNC LOAD’ feature hiccuping the clock when I load a song from the card. Depending on the downstream sequencer, they’ll survive the hiccup and keep playing normally or things get weird (my prophet gets off time whereas sometimes my Rytm just stops entirely). My hope was that by bypassing the pyramids clock with another, steady clock, that I could load songs on the pyramid without these clock error artifacts popping up. If I can feed a steady clock into the pryamid and that’s ‘the clock’, then I hope this will be an easy problem for me to fix.

I suspected a soft through as well, it seemed the pyramid does processing on whatever was coming into midi in, for example it’s re-routing of notes to your selected track. Usually I don’t worry about a soft through too much if it’s just a single hop in a midi chain, though not all soft thrus are created equal and I’ve had other issues with the pyramid’s clocking priorities.

Thanks again - that was a pretty solid experiment.

“ideally” what you said about midi thru is true. But this isn’t necessarily the case. There are both ‘hard throughs’ and ‘soft through’. A hard through would work as you described where there’s litle little wires that simply pass your midi messages from the input to the output. Soft throughs are fairly common though, and in this case there’s some software involved that migrates the incoming midi to the out going midi. Soft throughs have a variable latency.

Now, this isn’t the only way things could work. I’m an engineer so I have a tendency to over think things. Another option, depending on how the squarpies like to do things could be something where, a tempo is read from the input, then that tempo read is set as bpm value on an internal clock generator, where that clock generator owns the output (and the clock isn’t a thru in that case). It sounds like this definitely isn’t what’s though and that it is indeed a through (thanks to teachnobear for that).

My next experiment will be to suss out whether or not the squarp introduces latency on it’s soft through when loading a track. If that’s the case I think i’ll have to use mergers to splice in a clock signal and pull the squarp out of clocking entirely. More to come later.

Well, I did imply they were my presumptions based on my understanding…

I’m schizoaffective, have adhd, and too much creativity for my own good… So I understand the desire to overthink things.

As you say though I should have been more clear about “original signal”. If it’s been digitally read and then converted back it’s not really the original signal no matter how low the latency is…

I didn’t say you needed to be more clear, I just like to be helpful and I love talking about synth gear :slight_smile:

And, interestingly enough, I played with the pyramid a bit and there are a couple of clock contexts that make a difference. Maybe you or technobear will find this interesting. But, it looks like the only way to have a clock pass through is to somewhat cripple the pyramid.

An external clock is only gonna pass through when a midi port is set to THRU, otherwise while you can sync to the clock, it appears as though the pyramid has it’s own clock generator that’s simply configured based on whatever is read on the input. If one or both ports is set to THRU then the clock will simply be relayed to the output. If the midi output is set to OUT or OUT+THRU the external clock won’t get past the pyramid - you have to turn on SYNC for each port to get a clock to send in OUT or OUT+THRU modes and this clock seems subject to processing introduced latencies.

So, if you wanted an external clock to drive the synths you have connected to the pyramid, you’d effectively have to disable the pyramid’s ability to play any notes (you need to be in OUT or OUT+THRU for it to perform it’s sequences). Ah well.

I guess this means that I will be going with plan B, which is to use an external clock and some midi mergers.

1 Like

It’s chill… Like I said… schizo and overthink things… Also like talking about synth gear… and feeling way too isolated.

Very interesting notes you’ve brought up… I wonder if it would be possible to use the multiclock to just resync and clock everything from the pyramid by giving pyramid conductor duties and passing other stuff through different channels…

I have good news. I wrote squarp about my little problem, and the midi thru/clocking thing - they say that they are working on a solution that might be out this winter :: squee ::. They also confirmed my suspicions about how the midi thru/clock works. Here’s what I sent them:

Hey - there’s a clock hiccup that occurs if you use the SYNC LOAD feature, which is supposed to keep the clock running while you load your next song. This is pretty similar to the last clock bug I sent you (which has to do with displaying the menu of songs to load). Basically when you load a track the pyramid can’t keep it’s clock stuff aligned and this causes problems. For example, I have three downstream sequencers - Analog Rytm, System 8, and the Prophet Rev 2. When there’s a clock issue the Rytm stops entirely, my Prophet will just play things weird, but the system 8 is fine. Anyways, so SYNC LOAD isn’t really working for me because this clock hiccup really messes things up. Anyways, fixing SYNC LOAD timing is the bug I’d like to report; ideally the clock takes processor priority over the loading of the song. So I wanted to look into working around this by using an external clock. The idea is simple - if pyramid hiccups the clock when I load, can I just use a clock that won’t be affected by the pyramid loading a song. I’ve been figuring out how this might work, as there are some really nice midi clocks out there. The pyramid, while it will sync to the external clock, it doesn’t really let you use the external clock as a passthrough. Sometimes, if I put both pyramid output ports to MIDI THRU, I’ll see the clock work its way through the pyramid, but only sometimes (I’m not sure why I can’t make this THRU feature work consistently). Of course, Midi THRU is sorta useless because you need the mode to be OUT to have the pyramid play any notes. Midi out+thru doesn’t appear to pass the clock thru at all, which is pretty much how OUT mode works. It would appear that the pyramid will read an incoming BPM but ultimately uses that to set it’s own clock generator (and I believe this clock generator is subject to timing delays due to processing on the pyramid) Anyways - long story short, I can’t figure out how to make the external clock ‘the clock’ for everything via the pyramid. Is there a passthrough for external clocks? Can there be? This is my feature request, though if you have advice as to how to have a steady clock with the pyramid, I’d be all ears. Anyways, if you ant a repro, it’s pretty easy - just attach a sequencer to the pyramid that’s really sensitive (like the Rytm or the Prophet), start them, then load a song. There’s almost always an audible hiccup and you’ll likely notice your sequencers get weird. Another symptom you can look for is, I have some delays connected to the midi clock and they’ll briefly report some weird bpm that’s not correct.

And here is squarp’s reply:

I get exactly the problem you have, and it is something we are working on. I think we will come up with a firmware that fixes it during winter. The thing is that we are perfectly respecting the MIDI specifications, and even if saying this is not solving your issue, the problem is most likely due to other manufacturers (regarding their implementation of the “wait for clock” feature).

You are right about the Thru of Pyramid, which is not a real Thru, in the way that it is interpreted. We will also work on that, and it could be an effective workaround if we don’t succeed in making the clock robust with every other gear.

I guess all we have to do is wait a little bit and the clocking will get better :smiley:

1 Like

cool that squarp are listening and understand the issue

looking forward to the “winter update”

Very interesting. I am using the clock from Korg Microkontrol that passes through some MIDI mergers and a patch bay and runs other sequencers before it hits the Pyramid and then after the Pyramid other synths, effects and drum machines are using the clock again. Pyramid is set to sync to external clock and Midi on A and B is set to Out. I don’t see any timing issues but it surprises me to see that clock is not really passed through but it’s re-generated inside Pyramid for downstream use.

Squarp seems to be one of the most attentive and caring hardware manufacturers I’ve ever dealt with… This is good news.

1 Like

midi mergers/patch bays are passive…

Im not… and I suspect most tempo based sequencer works this way.
if you just passed the clock thru (when using midi out+thru/midi out)
then when the pyramid generated messages off its ‘grid’, these messages would be slightly off that clock.

instead, its syncronising its (internal) clock to the external one, and outputs this… so its grid is nicely aligned.

also this has the advantage, that the pyramid can smooth out the (inevitable) jitter that occurs with midi clock messages - so hopefully put out a slighly more stable clock. (*)

thats not to say, it couldn’t be made to work by passing thru the clock (and not output your internal clock), but I suspect it would just create a different set of problems…


(*) i think this is esp. the case, if your slaving to a DAW, where the OS introduces a certain amount of jitter if your using usb midi.


I agree, Ive always had a great response from them when Ive reached out- this is I why recommend users reach out via the contact form… Squarp can then contact you to really understand what it is you need, and also how they might be able to help… what is ‘feasible’ give the codebase and resources etc.

4 Likes

Hopefully, this is the right place to ask this. . . I’m wondering who should be my master clock in a setup that includes a digitakt, a tascam model 12 recorder, and a pyramid (and a hermod). Right now I’m letting pyramid recieve transport/clock from the model 12, and pass clock to the digitakt. It seems . . . fine? Does anyone have thoughts about who should be master clock?

I would say it depended on what you’ve tested within your set up to have the most stable clock for you. If you can test them with a DAW, that would be a good place to start recording click outputs or simply repeated notes.

Generally speaking it’s whatever you have that always clocks and plays well with others downstream. That may be the Pyramid, it may not… depending on whatever else you have connected… vague answer I know.

1 Like

@Ezmyrelda is spot on with this.

Id add that an additional yet rate factor to consider is if you do tempo changes and how you facilitate those.

It is easiest in my setup to use the BPM Fx on Pyramid to enact tempo changes within a song, so that is my Master.

I dont know about Digitakt and timestretch, but i use an OT on occasion (love/hate relationship- although currently on “love” with the 1.40 OS): if OT is not Master, then timestretch becomes unreliable. Which means since Pyramid is Master Clock, then any loops i may use on OT must be constructed at the correct tempo and things like using record trigs for stutters/repeats are caca clicky.

2 Likes

Thanks all, that makes sense that like everything else there’s no single best solution. I will experiment. Tbh, the arrangement I’m using seems to work totally fine. I guess I should probably stop trying to “perfect” my set-up and just get to making the music.
Thanks!

1 Like

midi clock can never be ‘perfect’ , all slaves will be slighly off and waver, and will take a short time to catch up to tempo changes… but we don’t need technically perfect, rather musically good enough.

you have your answer :slight_smile:

personally, unless I found an ‘issue’, in this case, Id go for which ever feels like its most convenient

does the model 12 have 2 midi outputs?
if not then the pyramid seems to have a minor advantage, since you don’t have to use a midi thru, as you can connect to digitakt to A , and model 12 to B.
(I avoid using midi thru if possible, and only do 2 jumps at most)


generally , I choose based on:
a) which devices needs to be the most ‘accurate’ or needs instant tempo changes
(e.g. OT when modifying audio , needs tempo changes not to be slewed!)

b) which is convenient
if Im using a DAW usually, I’ll often make that master, just because thats where its handy to have control.
similarly, if Im mostly working on the OT, that will be master - and at other times I’ll switch to the Pyramid.

I’ll admit in my setup , pretty much however I configure it, its ‘close enough’ for my use…
( when working in a DAW, I resist the urge as much as possible to ‘pixel peek’ :wink: )

if syncronisation is really important to you, then you need to look at solutions that include delay compenstation. at the simplest (but not 100% accurate) you can use delay compensation in a daw.
to get total control you needs something like the E-RM multi-clock, which allows you to set delay compensation per output.

but again… perfection is not normally needed, and chasing it will cost you both time, money and probably quite a few grey hairs :slight_smile:

btw: there are a ton of dicussions on this forum (and others) about use of midi clock, these might be interesting.

3 Likes

all slaves will be slightly off and waver, and will take a short time to catch up to tempo changes

Off topic, but I need to chime in here:
Generally and in most common cases with hardware, slaves follow midi clock exactly.
It does not take them any time to catch up with tempo changes as the tempo actually “pushes” the machines inner logic (from a firmware point of view).
It gets trickier if the slave device has its own internal clock with a higher resolution than the midi clock or in case of DAWs that have their own internal clock synced to the audio engine.
Saying that midi clock can never be “perfect” is true, but not in the way you state it. It can not be perfect because of delays introduced by the transport medium and possible information density on the midi bus, but those things are mostly not noticeable.

1 Like

not sure what you mean by this… please explain?

midi clock message 0xF8 is sent at 24ppqn , the gap between them is then used to calculate the tempo.
almost all sequencers would run a higher resolution than that, they therefore derive a tempo from this pulse (*) … and as mentioned, they smooth this so the clock doesnt jump around.
(given any midi message also on that same physical connection would delay it)

as for this in practice, Ive 3 sequencers here… Pyramid, Octatrack and Hermod…
in each case… none of them will instantaneously change tempo when the master changes.

(*) as opposed to ‘simple’ step seqeuncers which are pushed by a single pulse/trig.