Main problem with frequency modulation (aside from whether we *want* it
or not) is how to quickly alter the frequency of the sound.
Well, I realised that for any frequency changed expressed as an interval
(in cents, say), you would simply have to multiply the index increment
(used in processing the wave normally) by a constant factor that depended
only on the interval, not the frequency. Hence there wouldn't need to be
that much calculation!

Except, that if you express the interval in *cents*, that means 1200 per
octave! BUT maths comes to the rescue *again*:

If the factor is given as   2^(c/1200) (where c is the interval in cents)
then if you express c as c1+c2, the factor will then be:

  (2^(c1/1200)) * (2^(c2/1200))

Or even,
  (2^(c1/1200)) * (2^(c2/1200)) * (2^O)
  (where O is the number of octaves above; 0 for none, negative for below)

In this way, you can store a table of 12 factors for intervals of 100,200,300,
etc cents, and 100 factors for intervals of 0,1,2,3,4,... cents
And then multiply them together, whith a shift to change octave!

Ok, it would *also* want another set of factors for *negative* numbers of
cents, I forgot.

Problem with this, is it would most likely need to be done with floating
point, as some of the factors would be quite small. This would be quite bad
if using MMX for doing the AM modulation and mixing, as changing from one
mode to the other is supposed to be *slow* IIRC.

Perhaps would be possible to use fixed-point maths, or even *emulate* floats
with fixed point, as there's no *addition*, which would be the tough part
(addition would require normalising and all that guff; multiplication, AFAIK
you can simply multiply the mantissas and add the exponents; normalisation
would only be needed to make it kosher afterwards)...

...in fact, if you assume values less than an octave away, the magnitude of
these numbers is going to remain in the range 0.5 to 2, exclusive. In other
words, floating point would give *no* benefit there except freedom from
thinking. As such, I'd say keep it fixed point, and then shift for the
octaves, as said before :)

That's great. Now, how to convert a value of N cents -7200 < N < 7200,
into c cents and O octaves? and how to split that c cents into hundreds
and units? I don't really fancy using the % operator, ISTR it includes
division :(
How about use a binary-friendly unit, such that you can use bitwise
operators to extract the data? Supposedly 5 cents difference is around
the virge of detectability, and this scheme is only for doing
 (a)Tremelo/FM
 (b)Portamento
-in which case, nobody's going to say "Hey! That's off key!" because it's
not going to be any particular note for long...
So. Resolution is roughly 5/1200 per octave, which is about 1/240. Haha!
So we can use a *byte* to represent pitches within an octave! :D
SO. our new value of c in that representation, leaves
   16s=(c&F0)>>4 (close to a semitone, but it's a 16th of an octave instead)
   bits=(c&F)
   octaves=c>>8

Yep, this would mean 2 16-entry tables :) (or 4, for + and - versions)
 In fact, this arrangement is so good in terms of time and space efficiency,
that there would seem little problem using 9 bits per octave instead, seeing
as a short is already required. That would only require half of the tables to
be 32-entries instead of 16, for a total of... 96 entries total?

Ok, there would be *1* problem with this scheme: Someone could put a low
frequency tremelo that's a whole number of semitones wide, using a *square*
wave; this would be expected to produce notes in the same key, but would be
probably *slightly* off here, by about a cent or 2, in the majority of cases.
This would be particularly noticable if played alongside other tones that
the user might suppose would be equal- they won't be.

Still, I think the idea of having ~1200 table entries (about 2 or 3K?) and
having to do %s to separate cents and octaves, *just* to make that work
right seems dubious; Sure, 3K isn't much at all, but all these things add
up and can fill up cache (especially on older machines, and machines without
L2). I want Patel to be *FAST*! Like unnecessarily so ;)

It *could* be possible to increase the resolution of the bitop-friendly
octave division to be finer than 1 cent, but if it was to coincide with
another tone of the expected frequency, the beats would probably be
noticable. I say don't sweat it.

