I would be perfectly happy with using the already present input jack for this, i.e. to add TRS-MIDI to its capabilities.
To make this a really tight fit, the Midronome would also need to forward any other messages it receives to its MIDI OUTs, i.e. send a merged stream of its generated MIDI clock and the received MIDI. This would enable to insert the Midronome into an already established chain of MIDI control, e.g. like this:
The merge functionality is really a key part to enable integrating the Midronome as streamlined as possible. If the Midronome does not merge, I would need to use an extra merge component, like this:
Code: Select all
MIDI controller --> Midronome --> MIDI Splitter ==> receiving devices
(since my MIDI controller actually have 2 MIDI outs, but if that was not the case, I would need a splitter after the MIDI controller as well)
Code: Select all
MIDI controller --> MIDI merger --> MIDI splitter ==> receiving devices | Ʌ \--> Midronome --/
I realize this would of course compromise on the promises of the low jitter of the Midronome clock output, but the messages have to be merged somewhere either way. Perhaps also better to have a tight merging algorithm in the Midronome which prioritises clock over other messages? The merging functionality could also be a toggleable opt-in feature, making the user explicitly allowing the consequences it could potentially have for jitter.
Admittedly, the MIDI controller I have on my board already has a MIDI clock, but it is not as stable as I would want it to be. Which is why I am hoping that I could integrate the Midronome into my setup The E-RM Multiclock seems to be able to do this, as it has the merging capabilities, but it is really an overkill device for my use-case. If their smaller midiclock unit had MIDI In, and the merging capabilities, I think it would be a perfect fit, so maybe this is a way for the Midronome to offer a nice value somewhere "in between" the two E-RM devices?