Support |
On 2/15/11 10:30 PM, "Per Boysen" <perboysen@gmail.com> wrote: > On Tue, Feb 15, 2011 at 1:42 PM, mark francombe <mark@markfrancombe.com> > wrote: >> >> ...and Per, the midi choking you describe is surely only apparent on a >> per-channel basis (that was per-channel, not Perīs channel BTW) If you >> were sending a different type of message on another channel, do you >> think this would exist? > > Not so sure about that. The bottle neck is the MIDI Out port - and if > all MIDI channels are going out the same MIDI Out port its gonna be > crowded nevertheless. What we did back in MIDI Sequencing hardware > days was to use MIDI Out interfaces with multiple ports. Maybe four > parallel physical MIDI ports so you could assign outgoing MIDI in a > smart way and distribute the stream over those four lines. One small caveat, however, Per. Likewise, back in the 80's and 90's, we had a relatively large-for-the-time MIDI hardware studio: Atari Mega 4, Mega 2's, & 1040STfm's running 128 MIDI channels directly, SMPTE/MTC-synced to an analog 12-track as well as several other MIDI sequencers which were then used to expand the number of MIDI channels to an even greater number. Having so much MIDI equipment, we were likewise aware of the bottlenecks you mention, so we decided to do a few tests. What we found out was that, yes, you can bottleneck a port, but it takes quite a bit more MIDI data than one would usually think. It seems that a lot of the hardware manufacturers back in the '80s & '90s actually used that "MIDI choking" excuse as a red herring to hide the fact that they were using under-powered CPU's and lousy code priorities. That -- along with bad interpolation algorithms -- was also the reason for most cases of "zipper-noise" on many boxes, not MIDI oversaturation. For instance, I'd frequently use my Yamaha G10/G10C MIDI Guitar controller. It alone sends out note data plus continuous pitch bend on six MIDI channels, one for each string. Anytime you're so much as touching a string, it's manipulating pitch bend data, which is what makes is such a fantastic controller. However, you'd think this adds a lot of MIDI pitch bend garbage to clog up the port. Additionally, there's a whammy bar that can pitch dive all six channels at once, and a pedal input or two for adding continuous controller data (such as CC#7 for volume swells) to each one of those six channels simultaneously. Yeah, this thing should be a MIDI nightmare, slogging down the stream with scads of extraneous controller data, and adding tons of extra latency. However, depending on which synth I'm using, that's not necessarily the case. If I match it up with my Emu Morpheus or my Prophet VS, no problem; it sounds beautiful! Plug it into my Matrix 1000, however, and it's zipper-noise out the wazoo. Try it with one of my Roland or Kawaii boxes, and you can add MIDI lag and the occasional stuck note to those problems as well. This roughly matches what we saw when we tested in the studio. Yes, you *can* bog down a port with too much MIDI data. However, we found that you really have to send constant note, pitch-bend, and controller(s) data on about 13 or more channels simultaneously before you're going to run into that in the real world. Most of the other symptoms, as I said, are actually due to the CPU of the receiving device not being able to keep up with the amount of data. The problem is in the lap of the synth makers, not the MIDI spec. Some of these makers would cheap out on components, knowing full well that this problem would only ever show itself with the top 2% of power users. Others, as was the case I suspect with Oberheim & my Matrix 1000, had much better chops at engineering analog boxes than prioritizing digital bitstreams. But none of those manufacturers were averse to blaming MIDI when it served to help cover up their own bad engineering. Of course, today's more-modern equipment should be powerful enough to handle this amount of data without any real problem. So, in the end, I don't think that this one application is likely to cause any real MIDI choking on the part of the Gordius, IMNSHO. --m.