Hello I have the following midihub patch:
FROM A (Octatrack transport and clock)
TO B (Digitakt input with a THRU that goes to Analog Four)
TO C (Goes to an Analog Rytm)
FROM D (Novation Launch Control XL Incoming params)
TO D (Octatrack Input to receive CC from Novation)
TO B, TO C accordingly.
The idea is to have Novation control everything via midihub’s magic but keep the clock and transport from the Octatrack.
Now my problem is that when I do something quick with the Novation fader it will slow the clock down for all the devices
(Edit: When I monitor FROM A or FROM D while the tempo drifts when violently moving the fader I see no overflow messages)
DICHOTIC-MAIN-1.mhp (678 Bytes)
Does the same issue occur if you send the Novation XL controls to MIDI C instead, so Octatrack is not getting affected by the CCs at all?
Hey, back at the studio to test this.
If I bypass this chain:
So Octatrack receives NO input from the Novation (keeps sending transport & clock!), the problem keeps happening.
Also, another thing I didn’t mention previously is that the Octatrack tempo is NOT getting affected whatsoever, stays rock solid.
It’s like Midihub’s message queue is getting so many messages from a violent fader move that clock messages are getting buffered and delivered later.. If that makes any kind of sense on how MH works…
What happens if you bypass the FROM D input?
Is the Midihub ‘in the center’ for all devices, or do the devices also have direct connections between them?
Midihub should be giving real time MIDI messages priority, so even if there’s a lot of CC messages, the Clock events should get through in time.
Maybe there is a bug in that area, I’ll be able to check it out on Monday or Tuesday.
Hmm what you’re saying is bypass the input pipe and still see whether the tempo flux happens? Cause FROM D is the NovXL input. I’ll have an answer as soon as I go back to the studio.
Other than the Digitakt → A4 THRU yes, Midihub is the center.
I see, priority to these messages makes total sense! When I go back to the studio I will do more debug work too.
As a temporary solution I filtered out the messages coming from the Novation faders and going to the other devices.
What seems to be happening is that as the messages merge to MIDI TO B the fader is pushing over the clock messages.
As another test, I removed the virtual pipes so Octa sends the clock at MIDI B in case the Virtual pipe was causing some kind of delay but no, same thing happens.
As expected nothing bad but at the same time Novation doesn’t send messages. So Bypassing the Novation input stops the problem.
I’ve tried reproducing this issue by producing Control Change events at full capacity at 3125B/s into one DIN-5 input and sending clock to another DIN-5 input of Midihub, merging the streams into a DIN-5 output, it seems to work ok - I’ve tried 120BPM tempo and I find variation of ± ~5BPM (jitter of up to 0.96ms) at full load, which is exactly as predicted by calculating the estimated deviations under these circumstances. Keep in mind this deviation is momentary and overall the synced position should remain the same between devices as none of the data is lost. I think I can get this improved too with deviation down to ± ~2BPM (up to 0.32ms) by making use of MIDI status byte optimization in a future firmware version.
However, I’ve found a couple of bugs in MIDI Monitoring code which would show misleading information under full load conditions, so I took the chance to improve it significantly fixing the issues plus adding more clear wording in overflow conditions, so it is hopefully more apparent that it’s only the MIDI Monitor that missed reporting some events, while the events sent to physical ports went through fine, as they have critical priority. These changes will be released in the next software updates.
So in conclusion, I didn’t find Clock events getting significantly slowed down under these conditions, the deviations are within expectations.
If you find it causes Octatrack to desync, some additional info would be useful like a video & audio of what you observe when interacting with the fader.
Let’s try something super simple! (also this is another midihub device, all firmware up to date!)
FROM B → Octatrack clock & Transport
FROM A → Novation LaunchControl XL MK2 (controller)
TO A → Merge both to Analog Rytm
Video: https://drive.google.com/file/d/1wYhAU7QzEr0nkW8AFywlAw9q4Ar8zBe-/view?usp=drive_link
Second test:
Use the clock from Midihub, again merge to A
Video: https://drive.google.com/file/d/1nOvE4G5hJCCKRXo4PEdsdhw3nx9ZOqBD/view?usp=drive_link
Both tests hold the same results, midi clock gets skipped in favor of the CC messages, then the Elektron machines try to re-calculate the tempo and there’s a big flux. I think that those tests showcase what I’m facing.. I really don’t know what I could be doing wrong here..
midihub_debug MDH CLOCK.csv (210.5 KB)
midihub_debug OCTA CLOCK.csv (39.9 KB)
Thank you for the provided info. I will come back to this in a little bit.
1 Like
Hello @Giedrius did you find anything about this?
Not yet, I have to finish some work before coming back to this.
Cool thank you for looking into it!
Hey, I managed to make progress on this issue - there was a bug with the realtime message prioritization under full load conditions which can occur when moving multiple faders at once. I’ll send you a test build to try out, once it’s ready.
1 Like
Also happens when you move one fader but more violently (maybe quick up and down 2-3 times) Just adding this in case it makes a difference, but I’d guess that would push the load as well..
Great! thanks for this 
