Timing specs/precision

[FlavioB]

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

Hey Jesse!
In the pictures it might look like a mess, but I can assure you: doing pre-listening on your own setup and only pulling up your master volume when you feel/hear that it combines with the already running tune, is really helpful!

Thanks for your invite - of course you're very welcome to get in touch with me if you'd ever be in Switzerland/Germany/Italy...
F.

---

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

Many of us, including myself, do know how to actually play keys :-) I've been to music school between 8 and 18 or so... only keyboards (2 years) and then Yamaha Electone electronic organs... ;-)
But some are only there to just make noises (with hardware devices like sand-tubes and a mic, for example!) ;-)
F.

---

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.

Yes, we tried using a pure THRU unit, I think it was a KAWAI?! Anyways, most of the time the issue is not with the generating MIDI clock device: it's more the receiving device (sequencer, keyboard) which has a bad MIDI implementation.
I agree with the CPU thing: I do have some MIDITEMP MP-88 and I try to avoid doing channel remapping or such things - I just do some MIDI filtering, so that I won't clutter up with unnecessary MIDI data a device which only needs to receive MIDI clock.

BTW: is the MRCC already available?

[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

Hey Jesse!
In the pictures it might look like a mess, but I can assure you: doing pre-listening on your own setup and only pulling up your master volume when you feel/hear that it combines with the already running tune, is really helpful!

Thanks for your invite - of course you're very welcome to get in touch with me if you'd ever be in Switzerland/Germany/Italy...
F.

---

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

Many of us, including myself, do know how to actually play keys :-) I've been to music school between 8 and 18 or so... only keyboards (2 years) and then Yamaha Electone electronic organs... ;-)
But some are only there to just make noises (with hardware devices like sand-tubes and a mic, for example!) ;-)
F.

---

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.

Yes, we tried using a pure THRU unit, I think it was a KAWAI?! Anyways, most of the time the issue is not with the generating MIDI clock device: it's more the receiving device (sequencer, keyboard) which has a bad MIDI implementation.
I agree with the CPU thing: I do have some MIDITEMP MP-88 and I try to avoid doing channel remapping or such things - I just do some MIDI filtering, so that I won't clutter up with unnecessary MIDI data a device which only needs to receive MIDI clock.

BTW: is the MRCC already available?

We're pushing hard to get MRCC pre-orders shipped by early February and hope to open up sales by the middle of the month. Lots of work still left to do but the finish line is in sight.
Jesse

[SP-1200]

Is the latency constant, or does it vary?

I very strongly disagree with another commenters' assessment that timing issues are more often a product of the midi implementation of the receiving advice.

I am highly interested in a potential clock offset feature. It would also be welcome if the MRCC could automatically compensate for the latency it introduces. For example, if it introduced 1.4 ms of latency, clock signal would offset by -1.4ms.

Negative offsets are achieved in the E-Rm multiclock by filtering out the clock signal for 4 pulses, similar to 1 bar of pre-roll on a DAW recorder.

[FlavioB]

Is the latency constant, or does it vary?

I very strongly disagree with another commenters' assessment that timing issues are more often a product of the midi implementation of the receiving advice.

I am highly interested in a potential clock offset feature. It would also be welcome if the MRCC could automatically compensate for the latency it introduces. For example, if it introduced 1.4 ms of latency, clock signal would offset by -1.4ms.

Negative offsets are achieved in the E-Rm multiclock by filtering out the clock signal for 4 pulses, similar to 1 bar of pre-roll on a DAW recorder.

Of course you're free to disagree, but when you can prove with accurate measurements that the master MIDI clock is really tight, where do you think the issue will lay? In the MIDI cables? :-)

How would an automatic latency correction work with MRCC, when it should compensate for the latency it (the MRCC?) itself is introducing?

Negative offsets are actually simply positive ones - when the clock is stopped, you cannot apply a negative offset. It would be like saying "start 1.4 ms before I tell you to start"! :-)

[SP-1200]

Hi Flavio,

I measure using a rigol oscilloscope.

I use a multiclock to achieve the tight timing by offsetting the clock pulses until all my sequencers are as close to in phase as the multiclock will allow.

The issue is not with the cables of course. The issue is with the system, not just with the device at the end.  

It should compensate all the time. If it introduces 1.4ms, offset 1.4.

I already explained that it waits four pulses to send the negatively offset ones.

[oldgearguy]

Typically, to introduce a negative clock offset, you need to be the master clocking device.
A negative offset is achieved by delaying *all the other clocks* the amount of the negative offset.

I own an E-RM Multiclock as well as other hw sequencers.

Something like the MRCC is typically in the middle of a lot of MIDI/USB connections and if it's already capable of merging, filtering, rechanneling, etc the MIDI data, you're likely going to have yet another set of variable timing offsets introduced.  Having it find and delay all clocks coming into it to match a negative offset on one or more ports would be quite the programming challenge even if the hardware was initially designed to be capable of it.

The E-RM (and others like the Acme SND, the device from Australia who's name escapes me at the moment) is expensive for a reason - getting MIDI timing amd offsets accurate is a very challenging task best left to dedicated boxes.  Trying to jam clock logic into a routing device that may have inputs and outputs changed on the fly (even if you don't do that, others can and will) and have different positive and negative offsets would be a daunting task that would very likely increase the costs and delay delivery times quite substantially.

[Darryl]

Typically, to introduce a negative clock offset, you need to be the master clocking device.
A negative offset is achieved by delaying *all the other clocks* the amount of the negative offset.

I own an E-RM Multiclock as well as other hw sequencers.

Something like the MRCC is typically in the middle of a lot of MIDI/USB connections and if it's already capable of merging, filtering, rechanneling, etc the MIDI data, you're likely going to have yet another set of variable timing offsets introduced.  Having it find and delay all clocks coming into it to match a negative offset on one or more ports would be quite the programming challenge even if the hardware was initially designed to be capable of it.

The E-RM (and others like the Acme SND, the device from Australia who's name escapes me at the moment) is expensive for a reason - getting MIDI timing amd offsets accurate is a very challenging task best left to dedicated boxes.  Trying to jam clock logic into a routing device that may have inputs and outputs changed on the fly (even if you don't do that, others can and will) and have different positive and negative offsets would be a daunting task that would very likely increase the costs and delay delivery times quite substantially.

Nicely stated oldgearguy. The MRCC's development priority needs to be passing MIDI data efficiently, and the inclusion of a simple MIDI clock is a bonus that doesn't cause any discernible overhead. 

Though the MRCC clock looks to be quite good I believe it will be a better usability experience to have a master clock with physical transport controls. For most people a modern drum machine is a fine MIDI clock source. Most modern digital MIDI devices have decent clocks. In a professional setting where one must comprehend the total latency from MIDI keyboard press to audio output, a fancy dedicated master clock might make sense.

[FlavioB]

Hi Flavio,

I measure using a rigol oscilloscope.

I use a multiclock to achieve the tight timing by offsetting the clock pulses until all my sequencers are as close to in phase as the multiclock will allow.

The issue is not with the cables of course. The issue is with the system, not just with the device at the end.  

It should compensate all the time. If it introduces 1.4ms, offset 1.4.

I already explained that it waits four pulses to send the negatively offset ones.

OK, I don't know what oscilloscope my tech uses.
What I am not understanding is: how should/would the master clock be able to compensate? If the master clock is, in fact, the MASTER, then there's nothing to compensate for: it is the one giving the clock and that's it. But maybe you have another idea or explanation of what you mean with the "compensation" - I'll be happy to read about it (I'm not saying it won't be feasible or won't work!) ;-)

As oldgearguy correctly said: the negative offset is just actually a *positive* one (applying delay to all other clocks). There is no negative delay possible...

F.

[SP-1200]

Is there any information available on the latency introduced by routing hardware through this device? By how much are midi messages delayed?

---

Hi Flavio,

I measure using a rigol oscilloscope.

I use a multiclock to achieve the tight timing by offsetting the clock pulses until all my sequencers are as close to in phase as the multiclock will allow.

The issue is not with the cables of course. The issue is with the system, not just with the device at the end.  

It should compensate all the time. If it introduces 1.4ms, offset 1.4.

I already explained that it waits four pulses to send the negatively offset ones.

OK, I don't know what oscilloscope my tech uses.
What I am not understanding is: how should/would the master clock be able to compensate? If the master clock is, in fact, the MASTER, then there's nothing to compensate for: it is the one giving the clock and that's it. But maybe you have another idea or explanation of what you mean with the "compensation" - I'll be happy to read about it (I'm not saying it won't be feasible or won't work!) ;-)

As oldgearguy correctly said: the negative offset is just actually a *positive* one (applying delay to all other clocks). There is no negative delay possible...

F.

I must have missed this quotation, sorry.

The way that the multiclock works is that the outputs can be started and stopped individually.

When users press a button to start sending clock on an output, it waits to do so as in a quantized pattern change relative to the master or incoming external clock, much like selecting patterns on an Elektron box or launching clips in Ableton Live.

Tracks with a negative offset will actually send their clock messages ahead of the others and the incoming external master clock signal.

It does not actually delay all of the other outputs to achieve this; it is a real negative offset.

It's the combination of the two features, the quantized- or launching-style transport controls, and the offsets that enable the user interface to allow this to be easily programmed.