Not the same as the TODO list. These are ideas that I've been mulling
over that may or may not be appropriate:

-Multiple simultaneous modulations (of the same type): It's already part
 of the design that an instrument can have both FM *and* AM modulation at
 once (even though AM modulation hasn't been coded yet). However, the ways
 you can modulate the tones are quite limited, because you only have the
 small set of signals to modulate by.
 But with the tone part of the instrument, you can get different waveforms
 by having harmonics etc... What if for both FM and AM, you could have more
 than one modulating signal, each with its own frequency, depth and waveform?
 If so I would suggest probably no more than 2 each for this.

 There's also the question of whether modulation should affect all harmonic
 components together, or just the fundamental; with this approach, we could
 decide that each modulator could affect a specific part of the instrument,
 but then this gets a bit awkward- not because it'd be hard to specify, but
 because turning FM displacement into a frequency multiplier is a slightly
 significant calculation. If both FM modulators act on the same thing, we
 can simply add their displacements together and then convert that.
 But perhaps the calculation isn't significant enough to worry about. I've
 already spent effort on using LUTs and minimizing the overall size of them.

-Other waveforms that have easily generated shapes but significantly
 different sets of harmonics to what the usual ones have. Could maybe
 figure some of these out with some sort of spectrogram program??

-Filtered noise. Hacky algorithm to create a noise source with a relatively
 user-defined frequency spectrum(?), to address the small range of sounds
 creatable without samples. The intention is for this algorithm to be as
 fast as possible whilst still offering something roughly like a filter.
 Filter is *NOT* meant to be high quality, but it's for chiptune sounds;
 it's merely supposed to be user-definable to get a broad range of noises.

 General idea is similar to that of the pink noise generator or of Perlin
 noise. Each filter has 3 small arrays: 1 is to define the filter, and has
 a set of amplitudes (0<=amp<=1); 1 is to take sample levels of the noise
 source being filtered; the last is of calculated modifications to the
 noise. There would be (supposing the number isn't increased to give a
 broader spectrum) 8 elements per array.
 Now, each filter also has an 8-bit counter (I have trouble working out
 whether its cycle time is the same as one wavelength of a signal or not :P );
 when a bit in the counter changes (from 0 to 1 or vice-versa), the
 corresponding element of the modification array is set, with the difference
 between the current noise level and the sample held in the same element of
 the sample array, all scaled by the amplitude given in the element of the
 filter definition array.
 Then, the element of the sample array is set to the current sample.
 Finally, for *each* element of the modification array, you add (or subtract,
 depending on sign) the modification to the current noise level, and this
 is output.
 Why yes, this idea *is* full of holes! EG, should noise samples be taken
 before modifications have been applied to the noise or after? If so, should
 they be modified in a specific order? How should the counter be
 incremented- the fundamental of the note should end up represented by one
 bit of the arrays, but at the same time, if ...gah, my head hurts :P
 I feel this idea has something workable in it, but will require much
 figuring out. Having said that, it might turn out to be no less processor
 intensive than traditional filters- but I have no idea how those are
 implemented yet.
 It should also be noted that as each such filter requires its own bundle
 of state info (about 24 bytes?), it would probably be impractical for these
 signal sources to be useable in every place that signals could be used. Not
 so much for the memory cost as for where each chunk of data would go. I
 don't want to be defining high-level "signal generator" objects in some
 C++ish way, constraining the way things could be combined was part of the
 general idea of how Patel could stay that extra bit efficient. As such, I
 think that any "filter" soure like this should only be useable as a part
 of the tone, maybe just the fundamental. Trying to use it for anything else
 should produce something else- either a normal noise source, a sine wave,
 or *silence*. Probably the latter would be best, as it'd give away the fact
 that it wasn't doing what was expected.
 THOUGHT: Perhaps rather than having "filter" as a signal source, just have
 filter as a.... filter? Then it could be applicable on all waveforms, and
 perhaps not only on one part but on all parts? Hmm. Not sure I like the
 idea from the POV of constraining sound types, but from the POV of
 orthogonality and simplicity, perhaps... Decisions, decisions...
