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?