Mixedup wrote: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! :tongue:
(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 :lol: ) 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.