The Yamaha AN1x Synthesizer mailing list

>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