I saw that devices like Digitakt, Circuit Tracks, ... can control other instruments via MIDI. I also saw videos where the author controls two, three, ... synths with it. I understood on the controlling device you set channel, you transmit and on the actual instrument you set the same channel.

What I am puzzled about is how do you connect those things. I am pretty sure all the controlling devices mentioned above have only one MIDI out.

Do you chain the controlled instruments via MIDI IN/OUT?

[Controlling device] (MIDI OUT)————> (MIDI IN)[Controlled device 1](MIDI OUT) —————> (MIDI IN)[Controlled device 2](MIDI OUT) —————> (MIDI IN)[Controlled device 3](MIDI OUT)

And each instrument takes from the broadcasting just the channel he listens? Or do you need some MIDI hub/mixer for that?


Most MIDI devices have a third port "MIDI thru", and the input is passed directly to this port so you can chain devices. Sometimes the output port doubles as thru. Each device listens to messages on its own channel. For more complicated setups there are midi patchers/mixers available.

There's one downside to this: if you chain too many devices you might run into latency problems.

  • 1
    A real thru port is not adding latency normally as it is with nearly straight to the IN port in the midi specs. I might be misremembering thought – Tom Feb 28 at 17:24
  • 2
    @Tom: One problem with MIDI thru is that every device on the chain has to share the same bandwidth. If you transmit a message to one device, the message has to finish before you can send a message to a different device. In that sense, MIDI thru adds noticeable latency. – Dietrich Epp Mar 1 at 2:07
  • @DietrichEpp That's a very good point! If you are using only one device at a time thought, it does not matter if it is at the beginning or at the end of the chain thought... – Tom Mar 1 at 6:54
  • @DietrichEpp The controller has to finish sending one message before it can send the next one, but that latency has nothing to do with MIDI thru (unless you have a controller with several MIDI outs) – PiedPiper Mar 1 at 10:08

The general rule is don't chain MIDI devices if you can avoid it.

MIDI is in modern terms, dog-slow. Each time it passes through a device it has to be completely re-transmitted, whether it is acted upon or sent onward untouched.

If you need to be transmitting to multiple devices, use a hub - one re-transmission only.
Various devices shift clock in various ways. You're never going to know how any one device is going to treat a through-stream. Some will simply echo, some will reprocess. Some where the out & through are shared in one socket will re-interpret & interleave data.
All in all, that's going to makes things lose coherence & you won't know where in the chain it's happening.
It's actually been so many years since I ever had to do anything like this I couldn't even hope to recommend anything modern to achieve this. I actually still have my Yamaha MJC8 from the mid 90s, which is about the last time I ever had to route MIDI ;)

You can actually pour 16 channels of complex midi down one pipe & have everything appear to retain its timing. Unless you have the manufacturer figures for how each channel & message is prioritised you may need to do some of this by empiricism.

The basic rules are:-
Send drums absolutely on-beat [unless your data-streaming is getting so hideously complex you even have to start shifting hi-hats ;) Many multi-timbral instruments prioritise ch10 over all others [then 1, 2, 3 … 16 in that order), so send drums on 10 if you don't know how a device prioritises.
Send other fast attacks immediately after drums [or before if things get laggy - you can't send them all together, MIDI is serial] on low-numbered channels.
Send slow attacks early, so they feel on-beat, on high channels.
Send any other data - controllers & especially Sys-Ex - miles away from any significant beat.
Once you figure these out roughly for your devices then you can just use your DAW's delays structure to save having to do it all manually.
In the old days we used to have to do this in a MIDI File itself, so playback was ensured to be tight.

I occasionally like to drag out this old demo to show just how tight it was possible to get MIDI, if you knew what you were doing. This track was tweaked entirely by hand & what you hear is untouched playback of 16 simultaneous channels from one single device, over one cable, simply recorded directly from the stereo outs. No external FX, nothing touched, except a tiny bit of finalisation comp & EQ.
Some of the sounds themselves are of course, a bit 90s sounding now, but I still think we got the brass pretty darn good even for its age ;))
We had the benefit of the exact data on the unit itself from the manufacturer, so we could literally move data by the correct number of ticks to precise milliseconds to keep the data-flow optimised. You're unlikely to find that data outside the manufacturer. [To this day I can still hear one beat that lags about 3/4 of the way through the track that we could never truly fix.]
It's probably not truly apparent just from a casual listen to the full stereo mix, but we have at least 60 instruments going, squeezed byte by byte into 16 midi channels (the brass, for instance is not just "brass section" it's separate instruments). There's also a colossal amount of controller data & Sys-Ex flying around to control filters [eg for the wah-wah guitar, it's all done on the filters], bends, FX & mixer data.


Soundcloud used to inline on here like YouTube does, but for some reason it stopped doing that in the past year, so you've to click through these days. Sorry.

BTW, the myth that some sequencers were tighter than others was just that; a myth. So long as it could clock [which technology has been able to do since the first digital watches in the 70s] most misinterpretations of a sequencer or synth's timing was based on not understanding how to shape the data flow.

  • 3
    "Each time it passes through a device it has to be completely re-transmitted ", this is usually done without any delay (true bypass after the optocoupler) on the thru port if I'm correct (and this port not merged with the out one), no? – Tom Feb 28 at 17:19
  • 1
    TBH, I've never been involved with the actual electronics, not my field. I had only the manufacturer data on latencies, which included internal response times. We were far less concerned with through times. From what I understood, this was always far worse if the out was doubling as a through. – Tetsujin Feb 28 at 17:35
  • 1
    Haha, you always have such anecdotes that I would not have been surprised ;). Being slightly involved, I guess it depends on the implementation, but doubling out and thru is criminal IMO. – Tom Feb 28 at 20:06
  • 3
    "real" midi through (such like what hubs usually implement) does not re-transmit - it's just a form of amplification - i.e. providing enough current for each consumer. You can chain them without any practical limits. The rest of your comments is spot on :) – fdreger Feb 28 at 23:43
  • 1
    @Tom - Thank you. I was very involved with the practicalities of making these rather cheap boxes sound "amazing" on the demos, so that people would buy them of course. We had to do it without ever actually cheating. The box had to be truly capable of what we claimed. The amount of 'by eye & ear' data analysis we used to have to do to achieve this probably meant no-one else on earth would ever manage anything like it. We would spend a month on a track like this ;) Quick 'cheat'… Prog change, note on, PC, note on, PC, note off, PC, off… There ya go, one midi channel, two simultaneous sounds. – Tetsujin Mar 2 at 20:30

Historically, MIDI instruments almost always had 3 ports:

  • MIDI IN: takes an input and plays accordingly depending on its settings and what's being received (the correct channel or even key range);
  • MIDI OUT: sends the instrument keys and (some) controls to another instrument;
  • MIDI THRU: relays everything is received from the MIDI IN;

Note that, while OUT and THRU are both output ports, their events didn't usually match: you normally send events generated only by the instrument on its OUT, and you only get events received from its IN in the THRU port.

More modern instruments often merge OUT and THRU together (sometimes allowing to choose how it should behave, as an OUT, a THRU, or a combination of them); having two different ports sending output events also was for technical/economical limitations and conceptual ease, but in the last decades technology has become more cheaper and usage of MIDI has changed as well.

Having a MIDI chain is often a bit complex and risky, as you have to ensure that you always use the correct channel to control a specific device and that device only reacts to that specific channel, and that's not always practical (or even possible in complex situations).
Also, with "too long chains", you might face issues anyway: signal decays, latency, event loss, etc.

Using a MIDI thru box/switch/filter allows to centralize everything ensuring that each input only receives what it matters, and also allows to use devices that don't provide an appropriate output port which correctly relays received events (or you are not interested in them).

More advanced devices also allow port filtering and routing, so that you can just choose a channel for an output port, and you only need to ensure that the device connected to that port can react to any channel ("OMNI"). Some MIDI boxes also provide advanced processing, from simple channel changes, to key transposition, and also have "scenes" that can change processing or routing setup.

It all depends on the situation, the complexity of your setup, and the capabilities of your instruments.


I would like to add that in a MIDI chain you'll have a set maximum amount of instruments/devices. More recent midi (usb midi) have dynamically allocated midi channels without any set limit. Also, if you are running a VST(Virtual Steinberg Technology) as a polyphonic synthesizer, you're host application considers it a virtual instrument and is dynamically allocated MIDI device. VST on Macintosh platform are called Audio Units, I think. Dynamically allocated midi devices are configured to run alongside a MIDI chain.
If I'm correct, we now have dynamically allocated MIDI devices(no limit to devices/virtual instruments/usb midi) alongside our MIDI chain(set limit as a MIDI chain). The midi chain itself occupies an allocated midi device. Dynamic allocation greatly simplifies complex and confusing primitive MIDI routing.

Originally MIDI design functioned without the use of a host application(Cubase, Protools, recording studio, etc.) It was designed without the use of a computer in mind. If I'm not mistaken, in the early 80s whenever MIDI was available to the consumer, home music studio software wasn't very perfected on available 286 and even 386 architecture.

Anyhow, nowadays if you had 3 synthesizers, a drum machine, and a sequencer as external devices - they could be synced in chain to a source channel MIDI device's timeclock and all of this can happen without any multi-track recording studio software -- no computer. The point I'm making is that if you emulate synth or sound device software on a host application as a virtual instrument or audio unit, your midi devices availability are unlimited and only throttled to your CPU's performance threshold. Thanks to the technological progression in computer processors these past two decades, we have gone from barley emulating a single Yamaha synthesizer, to being able to emulate it 100+ times on a multi-core performance workstation.

Having MIDI routed in chain triggering external synths and sound modules are still deemed superior to a computer sound server as it retains the analog sound true to it's semi conducer circuitry and are not emulated on a dissimilar device.

  • 2
    You're kind of confusing internal computer routing with physical hardware routing. The stuff in computers is only called MIDI for familiarity. Though it uses the same controller structures, it's not really MIDI as we knew it. – Tetsujin Mar 3 at 19:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.