Timing specs/precision

[FlavioB]

Hi all!
Would it be possible to share the timing measurements for this unit's routing function?
Like sending a pure MIDI clock signal (please check with an oscilloscope that it is *very* neat!) and then measure on the MIDI outputs how the signal looks like (delay, jitter, ripple, ground noise/offset, voltage and current).
I'm struggling in finding such a MIDI router which really does not deteriorate too much the MIDI clock signal...

Thanks,
F.

[yomanfree]

Hello Flavio,
it seems that the conductivelabs are a bit busy, then I'm answering to help ...

you will find all the infomation concerning some early measurement here :
https://www.kickstarter.com/projects/the...ts/2656230

to summurize: That's early measurement on the prototype.
Latency is about 1.4ms (from midi input to all midi outputs, 1.4ms is the worst midi out value) and jitter below 400us. There is almost no latency between all the midi out.
(personnal comment: compared to other midi routers -without processing-, 1.4ms is equivalent to the best in class exisiting midi router latency).

This is for sure without some potential future effect processing etc ... it will increase the latency but I think that we can be confident. The MCU used is powerfull enought.

Darryl explained they will continue to monitor the latency/jitter.

For the MCU, the Darryl's communication:
https://www.kickstarter.com/projects/the...ts/2636355
(there is another communication about this point which describes the prototype MCU, sorry i've not been able to find it again).

hope it helps ...

[Darryl]

Hi all!
Would it be possible to share the timing measurements for this unit's routing function?
Like sending a pure MIDI clock signal (please check with an oscilloscope that it is *very* neat!) and then measure on the MIDI outputs how the signal looks like (delay, jitter, ripple, ground noise/offset, voltage and current).
I'm struggling in finding such a MIDI router which really does not deteriorate too much the MIDI clock signal...

Thanks,
F.

Yomanfree, thanks for sharing that link to the Kickstarter post. That's what I would have shared.

We will publish some new Latency and Jitter specs when we are about done with development.

I can't tell by your message what is the specific problem you are trying to solve. Is it latency and jitter? What is the symptom? That is, how do you know there is latency and jitter, can you hear it? If you can hear it, its bad   I assume you are using 5 Pin DIN and not USB since you asked about electrical characteristics of the MIDI outputs?

[milleborne]

Could there be a function to manually adjust midi timing +/- (push or pull in milliseconds or samples) right on the MRCC, in order to compensate for latency so that overall output can all be adjusted to sync?

[Jesse Johannesen]

Could there be a function to manually adjust midi timing +/- (push or pull in milliseconds or samples) right on the MRCC, in order to compensate for latency so that overall output can all be adjusted to sync?

I'm not sure how it would be possible to push a MIDI message? It has to receive a MIDI message before it can pass it, so it seems like this would need to be handled upstream, no?

[milleborne]

Could there be a function to manually adjust midi timing +/- (push or pull in milliseconds or samples) right on the MRCC, in order to compensate for latency so that overall output can all be adjusted to sync?

I'm not sure how it would be possible to push a MIDI message? It has to receive a MIDI message before it can pass it, so it seems like this would need to be handled upstream, no?

certainly not pushed, agreed, but delaying some streams to compensate is probably a more accurate description.

i'm thinking of use cases, for example, of integrating bluetooth midi (and multiple bluetooth devices), where latency seems to change based on where in the room i'm in! i've got a few yamaha bluetooth transmitters, and it seems like it could be useful if routed thru the MRCC.

but i'm wary of feature bloat too, so it's certainly not a "must have" feature -- i'm really happy with the dev of MRCC as it is already (it's plenty deep!).

thanks for the reply btw.

[FlavioB]

Hi all!
Would it be possible to share the timing measurements for this unit's routing function?
Like sending a pure MIDI clock signal (please check with an oscilloscope that it is *very* neat!) and then measure on the MIDI outputs how the signal looks like (delay, jitter, ripple, ground noise/offset, voltage and current).
I'm struggling in finding such a MIDI router which really does not deteriorate too much the MIDI clock signal...

Thanks,
F.

Yomanfree, thanks for sharing that link to the Kickstarter post. That's what I would have shared.

We will publish some new Latency and Jitter specs when we are about done with development.

I can't tell by your message what is the specific problem you are trying to solve. Is it latency and jitter? What is the symptom? That is, how do you know there is latency and jitter, can you hear it? If you can hear it, its bad   I assume you are using 5 Pin DIN and not USB since you asked about electrical characteristics of the MIDI outputs?

Hi Darryl - sorry for not replying earlier, I completely lost track of this!
So I am not trying to solve any kind of problem - yet :-) The whole thing started last year, at our annual synthesizer jam meeting -->

http://www.metunar.ch/st/st2019_nov.html

We had tremendous troubles with time synchronization between the participants and we tried to use different hardware for "sharing" the MIDI clock signal.
After that session, one of the participants suggested to measure the equipment and classify it on behalf of how good/bad the incoming MIDI clock signal gets sent out.

So we started measuring different equipment, based off a very clean MIDI clock signal. Cirklon, MOTU MIDI Express, Beatstep Pro and some other I don't recall anymore.
We've seen that the Beatstep Pro introduces the most ripple, the signal is not nicely square but it gets "rounded" and there's also jitter (this is the only one I remember the most details of, because it is *my* unit).

So yes, I was using 5-pin DIN MIDI connections - no USB there.

I've read about your measurements and they seem to be quite good indeed! Maybe I'll somewhen grab one of your units (as of now, I'm using Cirklon as master clock and 2x MIDITEMP MP-88 for distribution).

F.

[Jesse Johannesen]

That looks like a great event. I was a little worried that with that many cooks in the kitchen it would devolve into chaos, but having listened to some of those audio samples of the jams, it sounds really nice.

Here in Portland, before the apocalypse, I used to host a monthly event called Portland Synth Improvisors Collective where we would have between 14-18 people attend a synthesizer jam, but we set it up a little differently. Each table would have a mixer with 4-5 headphone jack outputs, and people would be able to choose a table to play at and then jam with only the 3 or 4 other people at their table. We would go for about an hour and a half then take a little break and folks could change tables if they would like to at that point, then another hour or so of jamming before calling it a night.

We would also run into the occasional timing issue. I remember one time we were trying to send an analog clock across the table by daisy chaining a couple stackable 3.5mm cables, which worked great until about midway through when the tip of the cable touched the stainless steel tabletop at which point the tempo just went absolutely haywire. It was quite a surprise and it took us a minute to figure out what had happened!

Anyway, thanks for sharing the link, and if we ever get back to congregating and you find yourself in Portland, OR on the 4th Tuesday of the month, hit me up.
Jesse

[Darryl]

The best results for timing is to use a MIDI Thru device that has no processing. When the MIDI device supports filtering, merging, channel mapping, etc, then the processor in the device has to process and dispatch every MIDI message. MIDI note data is very slow relative to modern processor speeds, but when you add 24 PPQ clock there's a lot more data to sort. A hardware MIDI thru has no processing or routing features, so its just electrically repeating the MIDI data and there will be no latency. Of course, this isn't always the best or most convenient solution for a complicated studio. For instance, my Sequential Circuits Prophet 600 was a version that was always OMNI, so it would listen to every MIDI channel on the port. A good case for channel filtering.

The good news is, modern microcontrollers are so fast, and have microsecond timers so MIDI data is no challenge to process quickly and accurately. Most things are happening in nanoseconds and the processor is just waiting for slow slow MIDI data. It makes us wonder why USB MIDI has so much latency on a Windows PC! We know why, because there is no priority feature in the OS that is available to the USB audio class driver. We think the USB MIDI performance on MRCC will be much better than a PC! One of the well respected legacy MIDI routers was the Edirol UM-880 and 550. They had a processor for every 2 inputs routed to the main processor, which they could bypass if there was no MIDI processing to be done. Fortunately we don't need to do this anymore, but in its day it was the best way to make it a great performer.

You can also introduce latency and jitter, and even corrupt data by daisy chaining MIDI connections from device to device. Some MIDI Thru ports are actually being processed at the input. The worst MIDI timing I've ever seen was with the Korg Kaoss Pad. It tries to "beat match" the MIDI clock, and immediately starts drifting. When we designed The NDLR, we used this lesson to handle external MIDI clock differently. We use each clock message as if it were our own internal clock tick. So what you send it is exactly what you hear. It works as a pretty good BPM meter too. The downside is, when the external clock stops, so does The NDLR.

[Darryl]

What a great collection of synths at your Jam session! And people who actually play the keys! I would have to use The NDLR :-)