>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
--
"My week beats your year." (l. reed)
====================================================================
Mike Metlay ∗ ATOMIC CITY ∗ PO Box 17083 ∗ Boulder CO 80308-0083 USA
metlay@... ∗ ∗ http://www.atomiccity.com