Geez Mike, You Really Know Your Stuff! That Was A Great Explanation!
Now, Wich Controller Do You Recommend That Is Fast On response (thin) And Has
Polyphonic Afterpressure?
Happy New Year to You All!
On Tuesday 30 December 2003 11:41 pm, Mike Metlay ++ Atomic City wrote:
> >Again, I don't believe I'm the first one to discover this, but AN1x's
> >filters are perfectly fine. It's the controllers. Maybe they were
> >trying to conserve MIDI bandwidth, maybe it was a design oversight,
> >maybe both, but the way the board generates midi controller messages
> >(which in turn feed the control matrix, according to the manual) is
> >sporadic at best.
>
> This is a real battle that every manufacturer has to deal with, and
> many choose to deal with it in many different ways so there's no
> universally "correct" method. The issue is one of trying to provide
> as much control in as little time as possible, while dealing with
> externally imposed limits on the equation. Follow along while I go
> into pedant mode for a bit, using MIDI as an example (even though, as
> I'll explain at the end, it may not be the culprit at all in this
> particular case).
>
> At 31.25 kilobits per second and ten bits per data byte (see
> http://www.midi.org, the webpage for the MIDI Manufacturers'
> Association, for more details), MIDI can at its most efficient only
> send 3125 data words per second into any given device. That's about
> three words per millisecond, which as a rule is under the limits of
> most humans' perception of delay, but that assumes absolute
> efficiency, no packeting problems, and no competition of events with
> one another in the MIDI data stream (e.g. notes competing with
> controller data or multiple controllers being used at once).
>
> Now, that's the number of data words per second. We then need to get
> the number of actual MESSAGES per second being sent. Most of the
> messages we're interested in have three data words per message: the
> status byte, the event type byte, and the parameter value byte. For a
> note-on, that's Note-ON/C3/Velocity 64, for example. For a
> controller, that's Controller/ModWheel/27 or whatever. (I'm going to
> omit a discussion of running status, which can speed things up a fair
> bit but not by so much that this argument is invalidated. Please go
> to the above website to learn more.) So, the rule of thumb is, 1
> message per millisecond, and (again, see the website) there's a
> latency of up to 3 milliseconds in the time taken to send such a
> message.
>
> For simplicity's sake, let's assume there's no competition and all
> you're doing is moving a single controller from minimum to maximum.
> That's 127 messages, roughly an eighth of a second. In a completely
> ideal world, that's about how long it takes to "snap" a controller
> from minimum to maximum, and so even the fastest movements should be
> smoothly reproducible with 7-bit resolution.
>
> Unfortunately our world isn't ideal. Control devices need to be
> polled periodically to see if they've been moved, and if they have,
> then a bit of "catch-up" needs to be played. Manufacturers
> deliberately slow and/or thin data transmission to assure that the
> MIDI bus doesn't have overflows and lose data, which can happen
> pretty easily. The problem is, HOW to handle these slowdowns is not a
> hard and fast rule.
>
> The two extremes of the spectrum are "thin but do not slow" and "slow
> but do not thin". The results are, in the first case, data that
> represents in real time where the hand of the player is but does so
> in a choppy, snapshotted manner, and in the second case, data that
> represents the entire movement of the hand of the player but not in
> real time. For an example of the former, check out the Doepfer Pocket
> Control, which thins out data to amazing degrees of coarseness as the
> speed of movements increases. For an example of the latter, check out
> the Encore Electronics Knobby, which broadcasts absolutely perfect
> movements but may take a second or longer to catch up with fast knob
> movements. (I measured the MIDI response of both units for an article
> I did a while back; we do such measurements as a matter of routine
> when we review MIDI controllers.)
>
> Neither is ideal, and manufacturers are constantly fighting to find
> compromises that work for most players. My personal preference, for
> what it's worth, is a smooth tradeoff between resolution and speed,
> so that very fast movements are coarse but slow movements have fine
> resolution. Then it's a matter of selecting an average data density
> that seems to work for your application. For many computer musicians,
> who can go back and paint in whatever resolution of data they need in
> their sequencers, only having a rough level of input data is
> perfectly fine: sketch in the general motion first, clean it up
> later. Naturally, the sequencer has its own, much finer data
> resolution than MIDI can handle, so controller streams can be very
> thick and still run in real time, assuming the data can be delivered
> that quickly to the MIDI devices...another advantage, at least in
> theory, for software-based or PCI-card-based software synths, which
> can accept and process data at speeds limited only by the host
> hardware.
>
> In the case of digital synths like the AN1x, MIDI may not even be a
> part of the equation; the slowness and/or erratic nature of the
> device's internal hardware polling may be the limiting factor. If the
> AN1x's CPU is too anemic to poll the ribbon fast enough and cleanly
> enough for a real smooth response, the player can hear this stepping
> effect even without using MIDI. It's a common problem on older
> modeled-digital machines, which are already working very hard to
> create sound before you then slam them with controller load. In
> theory, this is another advantage for real analog machines, which
> respond to voltage changes at the speed of light and don't have
> polling problems. Also in theory, as CPUs get faster and modeling
> code gets more efficient, we should see better and better behavior
> inside any given machine (without slapping on MIDI's ceiling) and
> this should become less of an issue--and that, alas, doesn't help
> matters for older machines like the AN1x at all, forcing us to use
> their coarse CPU response as a part of their inherent character.
> Behold, the dark days are upon us, and we are all labeled "glitch"
> artists because we can't afford the newest toys. Calamity and woe!
>
> Anyway, I haven't rambled here for a while and felt the need. I hope
> this gave everyone a bit of enlightenment. Best wishes for the New
> Year to all.
>
> mike