External MIDI Sync?

Hapax
1

Just wondering how people are getting on with clocking the Hapax externally.

I have been experiencing some issues with clocking the Hapax via my E-RM Multiclock, and wonder if others are experiencing anything similar. For example:

  1. I am noticing that the swing effect’s time offset will alternate between even and odd 16th note divisions.

  2. Patterns do not always launch on a bar division.

  3. I think I am seeing evidence of drift in my recordings.

I’m wondering if there are settings that I’m overlooking, or if external sync is still being refined, as is the case with other devices I’ve adopted early (TD-8, Medusa).

1 Like
2

I’ve only synced to my DAW via USB for recording so far (and then only once or twice) and haven’t noticed this, but will do some more testing tomorrow and see.

In the meantime, submit a bug report. I’ve found a few little things like this, which is to be expected at this early stage. Think the big bugs have probably mostly been found and filtered out, but there are bound to be use cases that the beta testers just hadn’t discovered.

It will be fixed, I am 100% positive.

3

Its not slaving properly from deluge so i decided to have it master. Works fine

4

@sketcherone
does the drifting happen quickly?
is the tempo being shown as the same?

does the hapax appear to be generally in the same position?
I mean if you put different notes on both sequences on 1,2,3,4 (of 4/4) do they all seem to be playing in time?

id wonder if the ‘reset’ is really syncing the start position properly.
or if it just a bit off… though that would not really explain (1)

do you ‘always send clock’ (though Im need to check if Hapax is following clock with transport off)

also if BEFORE you start the transport,
does ensuring the Hapax and the source are both set to same BPM help?

in the past Ive had issues if there are bpm mismatches before things start, and then the sequencer tries to catch up when it gets clock start - but by definition its already then out of time (slightly)
however, that is usually a fixed offset of (after clock has settled)

unfortunately, theres no settings on hapax … just where to get clock, and if to react to midi transport.
(ok, and some cv settings)

I did have it slaved to hermod at some point, and it seemed ok…
but usually, I have it as master, as it the centre of the system, and where notes are coming from , so makes sense for my setup.

If you can tell me what the problem looks like … i.e. how long does it take to materialise, I’ll try tomorrow with my Octatrack as master into Hapax, see if it gets along ok.

5

Im syncing mine with an Usamo from Ableton as master and its surprisingly solid. I have to off set the clock by 9ms in Usamo and I’m seeing very little drift.

Also have had luck making the Hapax master and syncing Ableton to it over USB. No luck at all syncing the Hapax to Ableton over USB though, it was all over the place, but honestly I think it may be an Ableton issue as I saw the same behavior with a T-1.

I will take a closer look though.

6

It seems to be delayed by a 16th note in a matter of a few minutes. It does seem that the shifts happen rather abrubtly, as in, I never hear things slightly off; when I notice something it’s pretty far out of sync.

The tempo display does rapidly display fractional numbers that are centered around the BPM I’m feeding it.

Not always- especially when launching from one pattern to another. But even without changing patterns, the tracks do tend to go out of sync with one another- possibly due to Midi FX but I’m not certain yet- I just often reach for the Arp or Swing, so can’t say that I’ve tested the issue w/o midi fx yet.

When this has happened I have confirmed that I haven’t accidentally altered any Elasticity settings: I keep it at 100.00%

Only sending clock upon transport. I do notice the Hapax seems to “remember” the last BPM value it interpreted. That said it will be the last fractional value interpreted.

As an example, after stopping the transport on a 120BPM setting, the Hapax is displaying 120.3, which is a considerable deviation from 120.0. I’m used to seeing things appear off in this way when I’m sending swing to a device, but in this case the Hapax is just getting stable un-swung clock.

I’ll have to check and see.

Thanks for looking into it! I will continue to test on my end and report any issues via the proper channels.

7

I just realised I have also encountered this.

The other night when a friend came over to jam, we had Reaper as the master, and that was syncing into Hapax and everything was running off that.

I had a delay pedal running off a synth, and we kept noticing it was drifting out of time. I had assumed it was Reaper being a bit funny. and as we were recording everything live anyway, just removed the USB sync, and hadn’t thought much of it at the time, but it’s definitely the same thing.

Just tested now, with one drum machine running into Hapax and the other running out of that, and it does the same thing.

So I wondered what was happening, and thought of MIDI Thru… which is turns out it is.

If you turn off MIDI Thru, then the two drum machines stay in sync, so the clock messages are being passed through Hapax, which is also generating its own clock messages, hence the sync issues.

I’m going to submit this as a bug to Squarp.

EDIT Bit more info I discovered: If I play with the Sync out settings, and if I set the Sync out on the MIDI output to anything other than “Clock+Transport” is doesn’t seem to start the machines slaved from Hapax. If I set it to “Only Clock” I just get the clock signal (although I think it’s the combined signal as above) and if set it to “Only transport” I it doesn’t receive any clock signal, not even from the Thru.

8

hmm, interesting…

we will always see the tempo moving fractionally (lets say arbitrarily +/- 1 bpm, or a a bit less), thats pretty much the nature of midi clock (which is far from ideal ;))

a 0.3 bpm at start, shouldn’t be really problematic… at high ppqn, thats going to get corrected very quickly.

very interesting that you say the sync changes (I assume without tempo changes from master)
… you’d assume, generally once its sync’d up, and following tempo, it would stay there

if it happens abruptly, that sounds to me like, something is happening that means processing intensifies for a very short period, due to ‘an event’, which delays clock processing…
so the question is… whats happening when this occurs?

lots of incoming/outgoing midi?
obviously the important thing here, is to try to isolate what the issue is.
if we do not have fx/swing is there still fluctuations
no point in introducing these, if the clock is not stable because they will obviously be out, and are a red-herring.
but if the clock is stable without these, and introducing one (e.g. swing) causes an issue this would give Squarp a very useful place to start looking.

so main take away is… whats the simplest use-case it fails.

then introducing one ‘complication’ at a time, to figure out which creates the issue.

so id avoid the ‘effects’ for now (e.g. pattern changing) thats likely due to clock instability (cause).

following this process, will also lead us to a scenario where we can help Squarp reproduce the issue… hopefully with any master clock… which obviously will mean they will find it easier to fix/test :wink:

note: its possible that the ‘event’ is not user related, it could be something like an IRQ storm , but thats not something we as users can help Squarp find… but we can help, by eliminating other factors.

one tech note… its be interesting for us to check if this only happens over DIN or USB, the code at the low level for these is likely different… so possible it might be better/worst on one that the other.

anyway, thanks for the info… given me some ideas for testing…

9

ok, so Ive done some tests… (and shared results with Squarp)

Setup:
Octatrack Master , 130 bpm
midi clock → din a into hapax

Octatrack plays kick, hi-hat pattern internally → audio interface LEFT → Ableton
Hapax → cv out → rample, playing same kick, hi-hat pattern → Audio interface RIGHT → Ableton

Observations:
OT always sends clock, and Hapax is constantly adjusting … so thats GOOD, its nicely sync’d from the get go!

test 1 - only clock/transport

just start it, let it run for 3 minutes, don’t touch anything :wink:

results:

there was ~5mS latency, caused by cvout->rample
(to be expected, we need track compensation to handle the scenario)
once compensated for latency, I see around 1-2mS jitter.
but thats seemed the same at beginning and end of test period.
and over test period, no increase in latency (i.e. slipping)

test 2- swing

does swing move clock out of sync
so same setup, but this time, I added fx whilst test was running
in particular the SwingFx, which I messed with settings during running
e.g. taking it to something like 60% 1/4, so I could hear difference

THEN , I removed the FX
what I wanted to see, was had we lost time? created a permanent offset?

results:

same result as first test.
once latency was compensated for, 1-2 mS jitter
and over test period, no increase in latency

as a side note…
I also compared the timing with lives 130bpm grid (by alignment, as it was not sync’d)
and both OT and Hapax were pretty much spot on.

so fundamentally, clocked seemed stable to me…
so still the hunt is on, for what might cause it to slip

also It be good @sketcherone if you can set your test up in a similar way I did to mine, then we could look at the results… again, with or without fx…
since you were not talking mS but, 1/16ths notes which is alot !

Im going to do a longer test now … whilst I go make some tea :wink:

1 Like
10

ok, did a 45 minutes test.

didn’t skip a beat, was the same in the first 15 seconds, and last 15 seconds, in step with Octatrack all the way.
It also perfectly matched up to Ableton ‘theoretical’ 130 bpm grid.

note:
I did not sync Ableton, so it had its clock manually set to same 130, then I aligned first beat to grid.
and checked audio was still in sync on few bars. both OT/Hapax did a great job!

11

important note - do not take numbers as golden, pinch of salt required

these ‘jitter’ numbers are rough, they are FAR from sample accurate!

the samples I used were just normal hits, so not ideal transients, nor did I compare at sample level.
I also only look at some of the data… so its representative, but not statistically accurate.

also when comparing two machines sides by side, both are likely to have jitter.
so the worst jitter case is a sum of the worst case on both machines, and you also don’t know how that is attributed. (more to OT or hapax)
similarly, there may be jitter in Rample, causing slight variations - difficult to assign where jitter is.

in numbers above, I (very) unfairly attributed all jitter to hapax :slight_smile:
(so although I said 1-2ms, this could easily be sub millisecond)

there are ways to get around these to get more accurate numbers,
but honestly, I don’t have the time or patience to get ‘sample accurate’ numbers.

BUT the main reason is simple - they aren’t really needed in the context of the OP.

( I only state, this in case someone wants to use these as hard data… this is NOT the case!)

12

This is the video I sent Squarp. It’s not jitter, this is sending out clock quicker than it’s receiving it, as it gets more and more out of sync.

Squarp have asked for me to test again and let them know, so will get back to everyone here as well.

13

OK, on further investigation, it’s not to do with passing clock signals through the thru. But I have discovered something very odd…

It appears, at least for me, if you have MIDI Thru set to all outputs, you get the sync issue above. BUT if you disable Thru on any one of the outputs then timing becomes solid again (there does seem to be some slight variation between the two clocks starting, but I think that’s just MIDI for you…

Par example, I have nothing plugged into MIDI Out C, but changing that setting breaks or recovers sync…

It’s not a CPU issue, either, as when I check that it’s around 7%…

But at least there is a workaround: Don’t put MIDI Thru on all outputs.

14

what’s your setup… im kinda confused…

the Electribe is master… and sending clock to hapax.
the hapax is set to receive clock from Electribe

you have midi thru turned on (to go where?)
why use midi thru, rather than clock out?

Im not sure I would expect midi thru to be 100% in sync with the clock… its kind of low level (presumably software) pass thru. (*)

the clock input is going to be driven by the midi input (clearly), to essentially drive the internal clock (from external source) - that will always have a ‘bit of’ lag, as theres processing to be done.

whereas Id assume midi thru, will be pretty much received and sent straight out.
so doesn’t need (and shouldn’t) be sync’d to the internal clock/sequencer.

so in this case Id be using clock(aka sync) out from the hapax to whatever it is your passing clock onto.

at least… thats what Id try…

p.s. Ive not tried this test with midi thru…so perhaps Im misunderstanding something here.
honestly, I generally avoid midi thru due to past fun with latency in chains - instead I pass out clock/notes to a midi hub, which then distributes to multiple devices ‘simultaneously’

(*) all that said, that does sound like more lag than Id expect :slight_smile:
though not tested in other setups to see if my expectation is correct.

15

Aye

In terms of this setup, it’s just for demonstration. I normally have the Electribe as a slave, but am using it as it’s an obvious clock out source and noticeable if there is a sync issue with another drum machine.
I normally have Thru enabled because my master keyboard goes into the Hapax, and everything comes out of it. Means I can play stuff from the keyboard without having to select a track, and also play different synths whilst editing another track (although the lack of Echo settings on Hapax has stopped me doing this for now). It also allows me to send CC stuff to different synths at the same time.

Yep, found this in the second video. Rytm is actually slower than the Electribe, not faster as I originally guessed

Yeah, since found out that the Hapax doesn’t pass through clock, which makes sense. But for some reason when Thru is on for all four outputs, it drops some clock signals (but not if it’s the Sync Master)

The second video explains more:

1 Like
16

Cool, sounds easy for Squarp to reproduce …. so hopefully they can fix.

17

i have something going terribly wrong in external sync… i think it happens randomly when muting /unmuting tracks … suddenly things are offset 1 beat, 1/16 … 1/32 … seriously unusable like this

but of course this is very hard to replicate

18

I’m working through with Squarp on this issue at the moment. Basically seems to be MIDI Thru causing the issue, with duplicating events and sending them out.

Workaround so far is to disable any MIDI Thru on ports you don’t actually need it. I’ve got it only enabled on A and B, which has massively mitigated the issue (at least for me)

They are working on it, though.

2 Likes
19

the thing is i have Midi Thru off. Never had it on.

I’ll watch the issue and try to replicate - once i figure out something i’ll update this thread and inform Squarp

20

my setup:
everything Midi over Copperlan
ERM Multiclock → Hapax
Hapax → Machinedrum

first finding:

image
image852×434 21.9 KB

upper recording is fine (small latency not yet corrected - but doesn’t matter as it’s stable and can be corrected)
lower recording is after i duplicated a pattern and switched to that pattern