I’m need a physical switch on a DIN MIDI channel carrying one uni-directional MIDI signal. It’s actually running over MIC cables (courtesy of short DIN5-to-XLR cables at each end), so I was hoping to use a MIC switch.
The Hosa GMS-274 accomplishes “Mic OFF” by shorting XLR pins 2 and 3 together …
Would such a switch work … i.e. disable MIDI and not cause any electrical problems???
I would try breaking either 2 or 3 OR both 2 and 3 instead of shorting. I believe the midi receiver has a ~220-300 ohm series resistor, a parallel protection diode, and an LED to transfer the signal to an optical receiver. If 2&3 (or 4&5 midi 5-pin din are shorted below), the resistor is taken out of the circuit the 5V (or 3.3V) generator side has no resistance and might overload.
breaking either 2 or 3 OR both 2 and 3 instead of shorting.
Thanks … except … I’m looking to use this Hosa GMS-274 off-the-shelf and was wondering if it would work …
I understand. If the sending side is built properly there should be a current limiting resistor to offer some protection. I’m concerned about shorting the pins and overloading the send side by taking out a resistor and the LED. Try it… Maybe some else has successfully shorted those pins and not let the smoke out.
OK, got it. Although I don’t understand the circuit diagrams, it looks like shorting 2 to 3 is a bad idea.
Will look for another solution … there is a MIDI “Kill Box” on Etsy that I will look into …
Thanks for the assistance!!
You piqued my interest. Seem like all the schematics break the circuit vs shorting the circuit. With an aluminum chassis, two midi jacks, a switch, and some wire I’m sure you could make one.
Some time ago I had to do something similar. I simply cut the power, inserted a small panel switch on pin 5 between input and output of the midi connectors. It works perfectly.
My use case is actually a bit more complex (a bit??).
My keyboard guy (PD) and I on Wind Synth (CG) each have a looper. We want to MIDI-sync our loopers, but one of our loopers has to be the master (which changes from song to song). Here’s the MIDI portion of our hookup:
Using all 5 leads of DIN5, I suspect we could accomplish what is shown as two switches and two wires with a single (dipole?) switch and wire. We would also need a gnarly Y-cable at each end to merge the MIDI In and Out onto a single wire (using pins 1 and 3). Is this advisable??
The control, if manual, could be operated by a double switch: when you switch one, you switch both.
In my case, I created a circuit where the In and Out flowed from the Keyboard (and then succeeded and went to the PC), I inserted the double switch that interrupted the feeds, simultaneously.
I purchased two pairs of cables, short, for the connections.
For me, it was the only way, but effective!
Did I understand your problem correctly?
This is having 2 midi streams running through one 5-pin DIN? One on pins 4-5 (normal pins) and other on pins (1-3). Assuming two would be a common ground. Seems ok to me; but I’d rather not have non-standard midi cables. What Sergio has shown would use stand midi cables.
Looking at your setup, something like a midisport 2x2 could be inserted between the four midi connections on the two switches (A box with USB, 2-midi ins, and 2-midi outs). That would allow the midi signals to flow into Cantabile via USB and cantabile routes could do the switching with song bindings based on which player is the master.
Replying to @Sergio here …
Yes, that is it! … for the simple setup. Both your MIDI connections are using pins 2, 5, and 4, and your switches are interrupting the signal on pin 5 on each MIDI connection.
To get more fancy, I was thinking of a single DIN5 cable for both MIDI connections. My switch in “Position A” would disconnect only pin 5 and when in “Position B”
And now I know why I posted this on the Cantabile forum … Sometimes I think we have to go through 14 mental iterations before figuring out what we really need …
So this is brilliant and clearly a much better approach … Thanks so much for sticking with the “Research” phase of this rig development effort …
One thought: the MIDI Interface approach would probably incur more latency. I’m guessing every round-trip in and out of Cantabile will cost 2x the audio buffer + other delay “stuff” …
Yes, latency would increase. But, if you are only linking master control signals it may not matter.
I’m actually routing MIDI Clock (24 PPQ?) as well as MMC, as well as CC2 Breath Pressure for my wind synth at 500 times / second.
I wonder what happens to a MIDI-synched device if it experiences not only latency, but jitter on a MIDI Clock feed … guess I’ll find out!!
Looks much cleaner. My only comment would be if you think you might need more midi IO, get a Midisport 4x4 for future expansion. Plus, all the Midi DIN connectors are on the back of a 4x4.
On the subject of design choices…
The approach I have taken is different. All of my keyboards only connect their MIDI (DIN or USB) to my NUC PC in a MIDI STAR configuration.
Cantabile is then acting as my MIDI Hub, Processor and Router that can change from song to song and also within song states.
I have a Roland FC300 MIDI foot controller with several switches that can be programmed as per the song needs, they can be set to be momentary or latching and set to any MIDI CC, again on a song by song basis, although I tend to have set CCs these days and handle any mapping needs in Cantabile.
I sometimes connect/disconnect MIDI routes in this way via bindings/states.
Just offering as a suggestion, as it could eliminate the need for your external switches and and thru/merger boxes, and all setup song by song within Cantabile.
That’s the direction I am moving. Concerned about the latency implications and possible MIDI jitter by routing MIDI Clock, but forging ahead and we’ll see where the bits fall.
I haven’t noticed any latency or jitter issues…
Cantabile is the clock master for all my devices. I do I wish that Cantabile could be set to send MIDI clock when the transport is halted, as that would be even better. When I start a song, you need to allow a little time for the synths to settle down. I did make it a Trello suggestion, but have not seen it yet…
I’ve routed MIDI Clock from one looper to another using a MidiSport 2x2 interface, and wound up with a bad case of MIDI Jitter. (oooh, great band name: “Clint and the Midi Jitters”)
First, the case that works: MIDI clock directly from Looper A to Looper B using a single DIN5 cable.
After a loop is set up on Looper A, a loop recorded in time with Looper B sounds like this:
WAV: Dropbox - MidiSyncBug_01_DirectMidiClkLinkBetweenLoopers_InitalRec_noJitter.wav - Simplify your life
MP3: Dropbox - MidiSyncBug_01_DirectMidiClkLinkBetweenLoopers_InitalRec_noJitter.mp3 - Simplify your life
Second, the case with MIDI Jitter: MIDI clock routed from Looper A, through a MidiSport interface, through Cantabile, back out the MidiSport, then to Looper B:
After a loop is set up on Looper A, a loop recorded in time with Looper B sounds like this:
WAV: Dropbox - MidiSyncBug_02_MidiClkThruCantabile_InitialRecording_Jitter.wav - Simplify your life
MP3: Dropbox - MidiSyncBug_02_MidiClkThruCantabile_InitialRecording_Jitter.mp3 - Simplify your life
I am guessing this is caused by jitter - variability in the arrival times of the [F8] single-byte Midi Clock commands.
A quick calc: The RC-505 produces 24 Midi Clock commands per quarter note. At 120BPM or 2 quarter-note beats per second, Looper A is producing 48 Midi Clock messages per second. That’s about 21 msec between MIDI Clock messages.
Using a 48 sample buffer at 48KHz gives a buffer delay of 1msec, which I expect to be the approximate variability between arrival of Midi Clock messages when routed through Cantabile. That’s a jitter of 1 part in 21 (i.e. 1msec in 21msec), or a variability of 5.7 BPM at 120 BPM, which is kind of a disaster.
I suspect that the receiving looper is experiencing this variability and getting a different timing from the original recorded time, so it is time-stretching my loop (poorly) and getting the stuttering sound.
This kind of blows the whole two-loopers-in-synch idea for me …
Any thoughts welcome …
