MIDI Channel 10 is bad for drums - fact or fiction?

[BillB]

I am starting to set up an Akai MPC1000 as the MIDI sequencer for my hardware-based studio. I plan to set up templates for MIDI recording, which will be consistent across the various synths, modules and drum machines.

I have read that, despite it being the General MIDI standard, Ch10 is not good for drums, with Channel 1 providing ‘tighter’ timing. As it is just a matter of the order of 4 bits in the MIDI message, it is not obvious why it should make any perceptible difference - unless, in a multi-Channel data stream, the drum voices ‘come tenth’.

On the other hand, with Ch 10 being the ‘standard’, sticking to it will offer higher levels of compatibility with a wider range of hardware/software. Purely as an example, the Akai Tomcat / Rhythm Wolf drum machines have fixed Ch10 assignment for the drum voices.

So, Channel 01 for tightness (or does it not matter?) or Channel 10 for GM etc compatibility?

Opinions please....

[muzines]

So, Channel 01 for tightness (or does it not matter?) or Channel 10 for GM etc compatibility?

It probably doesn't matter.

You can run your own tests if you like that sort of thing. The channel 1 thing came from early MIDI/software sequencers that processed events by track/channel, so when they would output MIDI notes on a given clock, they would run through in channel order - so any events on channel 1 would get sent first, then channel 2 etc.

I think (I should check) it was early Pro24 or Cubase that specified for the tightest timing, use tracks at the top of the track list, and events on MIDI channel 1, as they would always go "first" - and the more MIDI data in general, the more likely events on lower tracks and channels will get pushed back a little due to higher priority events getting sent first.

In your case, I don't think it will matter, so stick to 10 if it makes logistical sense.

[Ben Asaro]

I've been using channel 10 since the mid 80s. I think even if channel 1 is tighter, I'm so used to it I wouldn't be able to handle the change!

[resistorman]

I've been using channel 10 since the mid 80s. I think even if channel 1 is tighter, I'm so used to it I wouldn't be able to handle the change!

Ha!

Never heard of this, and I’ve been using midi since its beginning.

[Folderol]

It depends...
If you have a number of events happening at exactly the same time, channels are transmitted in sequence, but there is no such thing as the 'first' one in absolute time. However, ones carrying sharp attack instruments should ideally be as close together as possible, so leave drums where they are and put (say) a track with piano at 9 and brass at 11.

If they are a millisecond or more apart, it won't matter anyway, as channels are only transmitted when there is something on them to send.

Probably more relevant is don't use MIDI THRU if you can possibly avoid it - especially not on kit that uses active sensing.

[BJG145]

All I would say is, don't use channel 13. Your MIDI channels should skip from 12 to 14, like US hotel floors.

[Wonks]

Avoid it like the plague for drums if using a hardware MIDI sequencer to play everything from hardware MIDI modules. Zuke will tell you the first thing he and his other programming mates did back in the 80's and 90's was set the drums up on channel 1. The drum machines often had their own timing foibles, so you didn't want extra timing issues being added in. Channel 10 drums were noticeably laggy.

But for modern software MIDI within DAWs? I doubt it makes any difference at all now.

If you're not sure, then just try recording a part on channel 1 and then channel 10 and seeing if you can see any timing differences on the resulting waveforms.

[BillB]

Thanks for all the comments, folks.

Resistorman, it’s definitely ‘a thing’, although I can’t recall the source(s) - seen it several times over the decades.

Desmond, I’m sure you are right that it is something archaic from the early days of multi-Channel sequencing - it would be interesting to know what / when. Not sure what search term to use on Muzines....

Will, good point about using softer sounds with higher channels, although assuming that synths have been pre-allocated channels (just to maintain the sanity of a fixed system) no one synth will always be on, say, string synth duties. So that one may have to slide a little.

As for avoiding Channel 13... I shall be scientific, like NASA, and boldly jump regardless into one of the most unlucky missions ever. There’s no room for superstition in MIDI, or Apollo missions

Another thought is that the MPC has two MIDI outs, so it would be possible to dedicate one to the ‘drum modules’ (Volca Beats, TR-626, EMX1, Alesis DM5) although these would have to go via a Thru box or switch. Other possible percussion sources (eg JV-2080) would just have to carry on via the other outputs with the rest of the synths. Notwithstanding Will’s advice about avoiding Thru, it is not possible to avoid having one/some somewhere, so maybe a single Thru box feeding the drum units.... I think you can get away with driving two MIDI inputs from a single MIDI out via splitter lead, but four might be pushing it!
just when I thought I had finished wiring MIDI

Thanks for you thoughts, any others are welcome

[BillB]

Thanks, Wonks, so it is ‘a thing’, I didn’t just make it up...

I guess you are right, I should really do some scientific tests

But maybe, if drums are run from their own port and not in the main 16-channel stream, the ‘drum’ channel wouldn’t make any difference.

[The Elf]

This all comes from the early days of MIDI. Nowadays I doubt it's an issue at all.

[BillB]

This all comes from the early days of MIDI. Nowadays I doubt it's an issue at all.

Even in a hardware-based system?

[Moroccomoose]

I guess most modern midi is now either in the box or goes through USB, so most instruments have their own port, and unless you are really hammering multi timberal, I'd wager there is rarely much more than one channel in use most of the time anyway. So I'd be interested to know more about how the timing between ports is managed.

That said I have just set up my Cubase template for a Proteus Virtuoso for orchestration. Its an old school rompler, with 32 MIDI channels over 2 ports and 128 voice multi timbral. Interestingly, I have set the channels up to reflect the orchestra pit, left to right and front to back. This means that all the slow attach stuff (Strings) are using the lower channels and the fast attack stuff (Brass and percussion) is all in the higher channels.

While I am convinced that I will never be able to hear any discernible timing discrepancies - especially after they have gone through Elf's reverb delay technique (from another recent thread), I wondered if there is a MIDI standard or protocol which defines how orchestral instruments' channels are arranged, beyond channel 10 for percussion. And if there is, whether it is sensible given the points raised in this thread.

Stu.

[BillB]

I guess most modern midi is now either in the box or goes through USB, so most instruments have their own port.

Yes, that's how I have it when driving from a DAW. I'm lucky enough to have a couple of UM-880s and a UM-550, so most things have their own port.

But when you are looking at driving from a hardware sequencer (albeit one with two ports), channels are the only way to direct parts to devices, thus the question.

Apart from GM drums on Ch10, I am not aware of any MIDI protocols which propose a relationship between instrumentation and channels. But who knows: someone, somewhere, probably has! GM is mainly concerned with having program change numbers per instrument, plus various standard controller messages.

Having said that, and based on some of the comments above, I think I will be setting more percussive instruments (eg monosynths likely to take bass duties) to lower channels). Apart from that (and drums) it is likely that any system that makes sense to you is a good one.

[Martin Walker]

I think (I should check) it was early Pro24 or Cubase that specified for the tightest timing, use tracks at the top of the track list, and events on MIDI channel 1, as they would always go "first" - and the more MIDI data in general, the more likely events on lower tracks and channels will get pushed back a little due to higher priority events getting sent first.

This - I certainly remember reading it about happening with Cubase (and may even have written about it at the time as well )

As Desmond says, I doubt that it would make any difference timing-wise nowadays, although bets might be off if you overlay loads of controller & pitch bend messages on your drum MIDI note data stream.

Martin

[The Elf]

This all comes from the early days of MIDI. Nowadays I doubt it's an issue at all.

Even in a hardware-based system?

Buyer beware. I doubt that all hardware is made equal.

[BillB]

This all comes from the early days of MIDI. Nowadays I doubt it's an issue at all.

Even in a hardware-based system?

Buyer beware. I doubt that all hardware is made equal.

So... it may be an issue...

I'm not trying to make a big deal about it, just to understand whether it should be a consideration in designing a channel-based template for the MPC1000.
I have everything from 'probably not' to 'yes definitely' at the moment
... which is fine - all interesting comments.

[BillB]

bets might be off if you overlay loads of controller & pitch bend messages on your drum MIDI note data stream.

Good point, Martin. It would be sensible to keep percussion channels (ports!) clear of controller info.

[Wonks]

I think you've misread Martin's comment. The data will be on the drum stream as it's affecting the drum sounds.

If it's a hardware unit, just make the drums channel 1 and stop worrying about it.

[The Elf]

This all comes from the early days of MIDI. Nowadays I doubt it's an issue at all.

Even in a hardware-based system?

Buyer beware. I doubt that all hardware is made equal.

So... it may be an issue...

Well the problem is that unless you know how the software within the hardware is functioning it really is impossible to advise with certainty. When we were all running Commodore 64s and Atari STs then I can tell you that there definitely *was* an issue using higher channel numbers. These days, with ultra-fast processing, there's really no reason it should be an issue. But when cost-cutting and human error enter the fray...

I'm with Wonks - if the potential troubles you then use Channel 1 and end the speculation.

[BillB]

unless you know how the software within the hardware is functioning it really is impossible to advise with certainty.

Accepted, in the end all I can expect is people's experience and practice...

I'm with Wonks - if the potential troubles you then use Channel 1 and end the speculation.

Hah - it troubles me if it is a problem... thus the reason for asking. The disadvantage of setting drums to Ch1 is that you lose out-of-the-box compatibility with the majority of new hardware or software introduced into the studio (like the Tomcat example I gave - HARDWIRED to Ch10!). That's the conundrum. If it was an entirely isolated system and I was never likely to introduce or connect to anything new then yes, Ch1.

[Wonks]

Once you use a standard DIN hardware MIDI connection, then you are constrained to the 31250 bits per second of the MIDI standard. So if you have several notes all being sent at the start of a bar on other channels sending messages out on lower channels before channel 10 will delay the sending of the drum note message until those other lower channel note details have been sent.

'Running Status' MIDI messages allow multiple note on/off messages to be sent in sequence without having to send the MIDI channel number at the start to reduce the number of message bytes sent (a MIDI message byte is 10 bits long as it has a start and stop bit as well as 8 bits of data). So using this 'running status' form, a six note chord would take up 13 bytes, instead of 18 bytes if each note was sent as a separate entity. 13 message bytes is 130 bits, so that message would take 130/31250 = 4.1 ms to send. Add in a few more messages like that on other channels below channel 10, and you can see that you can easily get noticeable delays of 20+ms. What's more, with less messages sent on other channels, that delay time from the beginning of the bar (or 1/4 or 1/8 note position etc.) can change each time so it may be 5ms or it may be 30ms. Very noticeable on sharp transient drum sounds, less so on soft attack pads.

But this all depended on the sequencer used. Some used the channels in order from 1 to 16, others prioritised channel 10, then 1-9 and 11-16.

But within software to software MIDI transfers, the software isn't limited to physical serial transmission speed limitations , so it gets transferred within microseconds worst case.

[BillB]

But this all depended on the sequencer used. Some used the channels in order from 1 to 16, others prioritised channel 10, then 1-9 and 11-16.

Thanks, Wonks, that is interesting and pretty scientific! Especially that some devices may prioritise channels. I guess an easy test would be to set a note on exactly the first beat on every channel, run it into MIDI-OX and see if they go 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 or 10,1,2,3,4,5,6,7,8,9,11,12,13,14,15,16...

It may not matter if all the drum data goes via a dedicated port, but it would be good to know if it makes any difference in a mixed channel data stream...

[Mixedup]

Hmmm... interesting. Back in the arse-end of the '80s, when I started making MIDI-based music on an ancient IBM clone, my sequencer's (Prism) manual was very clear that it assigned a higher timing priority to MIDI channel 10 than any other channel, and recommended using it for drums. I can't say I noticed any timing issues working that way, but I was a young whipper-snapper back then and probably knew no different...

(I acquired an electric guitar in 1990 and promptly eschewed all things MIDI for a good decade or so )

Did they have it wrong, or did different software treat things differently back then?

[muzines]

Hmmm... interesting. Back in the arse-end of the '80s, when I started making MIDI-based music on an ancient IBM clone, my sequencer's (Prism) manual was very clear that it assigned a higher timing priority to MIDI channel 10 than any other channel, and recommended using it for drums.

There was a time *before* GM, you know!
(Ie, the MIDI sequencing years 1983-1991 - yes, GM standard came about in 1991)

The whole "MIDI Channel 10 for drums" thing largely came about because of the GM standard. After that time, some sequencers may perhaps have given priority to channel 10 events. Before that, however, in general higher tracks had timing priority, as tracks were usually processed from top to bottom.

Basically, there is no "this channel is best" because it's *all* to do with the sequencer's implementation. As long as you have plenty of bandwidth and aren't trying to put too many events on the same rigid clock position, things are generally fine. The moment things get cluttered is where some event jostling takes place, and the exact behaviour will depend on the events, and how the sequencer works.

For example, some sequencers may go in a loop and work from channel 1 up when outputting events. Some sequencers may place recorded events in a list/queue, and output the events in queue order, rather than channel order. Some sequencers may be designed to say "let's handle MIDI channel 10 events first, as we give those timing priority". It all depends on the implementation.

Testing can be fine (if you want to avoid doing anything productive, and yet still *feel* productive ) but really, make some sensible decisions based on your use cases (eg, lets put critical timing stuff on port 1, and the washy stuff on port 2), or, if you've got a *lot* of timing critical stuff, spread it over two ports - and make music.

If you notice a problem, then investigate *then*, rather than necessarily try to fix a problem you don't yet have.

[Ben Asaro]

I often have multiple channels going on simultaneously between my TX7, JV-1080, and DR-550 which is on channel 10, all from an MC-500. I’ve not noticed any lag beyond the normal start/stop lag on the MC-500. I mention this because all of this kit is mid-80s or mid-90s vintage, and I’ve not had any call for complaint.