Sim'n Tonic Forums

Original topic: viewtopic.php?t=36

This is about implementing the possibility of sending MIDI Data from the USB port to one or both the MIDI-DIN ports. The MIDI Clock will have priority so the MIDI Data will be moved around it.

The Midronome will have two more USB-MIDI input interfaces on the computer, called "Midronome MIDI Out 1" and "Midronome MIDI Out 2" (on top of the current "Midronome Commands") where the data will have to be sent to.

Note: This feature could be combined with a simple add-on module with a MIDI-DIN input to be able to forward data from a MIDI-DIN input.


Important notes about the implementation:

• Clock always has priority and is totally undisturbed by other MIDI data, no matter how much is sent (jitter will stay the same)
• Start/stop also has priority, and is also undisturbed
• The forwarded data will be sent in under 0.2ms after it is received, in the same order. Extra latency might be introduced if there is a Clock, Start, or Stop message (since they have priority).
• The device has a queue of about 700 MIDI bytes which can be received over USB before they are sent to DIN-MIDI. Because USB is much faster, this limit can actually be reached if the USB is spammed with messages faster than they can be sent over DIN-MIDI. Once the limit is reached new messages will be lost.
• Sysex messages can be max 125 bytes long - longer Sysex will be ignored (lost).
• If MIDI Start needs to be sent (f.eks. when pressing Play or when a resync happens) and we are in the middle of sending a long Sysex message, the Sysex message will be interrupted right away (so that MIDI Start can be sent in time), and then sent again from the start right after MIDI Start. This is not the case for MIDI Stop, and not the case for Sysex messages of 6 bytes of less (including F0 and F7).

(so basically: avoid long sysex messages, if you have a long one break it up in groups of 125-bytes, and avoid sending it/them just when the device needs to send Start - FYI a 125 bytes-long Sysex message will take 40ms to send)

Feel free to comment here regarding:

• If you think some information is missing or unclear
• How you would like this feature to be implemented (buttons, settings, how to activate, how it is done, etc.)
• Why you think this feature is a good addition to the Midronome

A simple pass-through of MIDI data, in addition to the clock, would turn the Midronome into a very nice 2-in-1 product. There were comments about MIDI routing and the potential costs and complexities, but personally, I already have sufficient routing in some other units, and with just 2 DIN ports, there's not a huge need for splitting and merging. Probably most with enough devices to need a routing interface will have one, and if not, the ports needed would far exceed two, anyway. On the other hand, when taking the Midronome out from the studio to a portable setting, it seems like a great addition to be able to use it as an interface as well as a clock source. I would just want a menu option to switch between clock only and clock plus all data.

Seems like, during testing, that some capacity testing would need to be done to get an idea of just how much other MIDI data can flow through each port without disturbing the clock. This'll surely be asked, otherwise. Automation of many parameters of a DAW VST editor out to one or more synths would probably do the trick. I suppose if someone is sending multiple tracks through the Midronome to a MIDI Thru out to 12 poly synths or something, even just notes could add up! Etc.

The AVR based MidiGAL has built-in MIDI Thru, and can also fix a sluggish incoming DIN MIDI Clock at the same time.

viewtopic.php?p=1322#p1322

We had a short chat at Gearspace with Joe_K (jmkmusicpedals) about how clock has realtime priority in the MIDI specs, yet the MidiGAL on test mode showed Note On messages to have less jitter than clock in many software DAWs or hardware controllers (Keystep for instance).

https://midisizer.com/midigal/midiclock-tester/

Thanks Foksadure Does that mean you would wish the Midronome would correct bad MIDI Clock timing as well? or MIDI Note timing?

Dave wrote: ↑16 May 2023, 01:50 Seems like, during testing, that some capacity testing would need to be done to get an idea of just how much other MIDI data can flow through each port without disturbing the clock.

I've already started the implementation - see the first post

Simon wrote: ↑27 Jul 2023, 18:59Does that mean you would wish the Midronome would correct bad MIDI Clock timing as well?

Exactement, that would be the idea.
AFAIK, there's no device that can correct a jittery USB MIDI Clock and distribute it on several DIN MIDI ports.
This could be an alternate way of syncing hardware gear to a DAW, albeit no as precise as the audio sync method but much simpler to setup.

The MidiGAL does the job, but is DIN MIDI only.

I think the Access Virus synthesizer series have such an algorithm, to avoid audio artifacts in delays FX when synced to a sluggish external MIDI Clock.
https://fr.audiofanzine.com/rack-modeli ... -midi-288/
The concept was then developed and sold to Steinberg for the Midex 3 & 8 USB MIDI interfaces. That's LTB:
https://gearspace.com/board/electronic- ... st16439339

Foksadure wrote: ↑28 Jul 2023, 12:54 Exactement, that would be the idea.
AFAIK, there's no device that can correct a jittery USB MIDI Clock and distribute it on several DIN MIDI ports.
This could be an alternate way of syncing hardware gear to a DAW, albeit no as precise as the audio sync method but much simpler to setup.

The MidiGAL does the job, but is DIN MIDI only.

Well the only way I can think of, which is probably the way the MidiGAL does it, is to interpolate the clock, only looking at say 1/24th of the clock pulses, i.e. the way I intend to do it for this feature - viewtopic.php?t=268.

But that means the sync will never be super tight, for example a quick tempo change will come a little bit later on the Midronome, as it will adjust back to follow the incoming clock.

FYI - this is now implemented and released as part of FW 2.0.

A bit late to the party, but many thanks for that!

Ha ha well better late than never! Glad it was useful to you