TODO:

NEXT:
=====

-Implement the other external utilities (using libPPF which should be
 complete now) to greatly simplify composition and editing etc. Without
 these, it's possible to make simple tunes by writing (or editing) the PPF
 data by hand, but that's absolutely horrible work. There's only the one
 useful utility ATM, which turns simple score files into PPF with only one
 instrument and one channel. Mostly the sort of utilities planned are just
 primitive command-line tools for batch-processing, pipelining and scripting
 in order to process PPF files in various useful ways to build up a piece
 of music.

-One external utility should be a simple tracker-style editor (for a
 limited amount of functionality to keep it simple), another should be an
 instrument editor. Something for merging instrument lists into other PPF
 files would be important too.

General:
========

(Old list)

-Just about everything

-Option for output to sound card rather than just WAV files; SDL (not
 SDL-mixer, just SDL) seems able to do this in a fairly cross-platform
 way, but apparently insists on using threads and it's probably an extra
 layer that'd add overhead; so ideally, I'd like to support SDL output
 *and* native APIs for various drivers. Compile-time options I suppose :)

-Add an RC wave
 [Probably several in fact, for different multiples of time-constant;
 possibly have reverse RC wave too?]
-Add some sort of pulse wave
 DONE, made it width of 1 in 8 (1:7 and 7:1 duty cycle, depending on
 direction of pulse). This should work up to ~4000Hz at 32000Hz samplerate,
 don't remember what I decided would happen when played at 8000Hz samplerate,
 except that it'd sound wrong :D
 4000Hz should be around the top frequency for tones, but should be
 possible to have higher frequencies using overtones and things, if I
 don't change the semantics of that (from absolute frequencies to fixed-
 -point multiples of fundamental frequency); still, should be possible to
 have non-specific frequencies above that using harmonics.

-Add NOISE! Possibly both white *and* pink? Could implement with tables,
 like perlin or something.
 Mostly done, needs more debugging; RNG needs MUCH work; I looked at using
 Mersenne, but it looks complicated. How about "Linear feedback shift
 register" for one, perhaps the bit-generator?
 Generators want to have state info entirely contained in a structure,
 settable by a seed, so users can select a noise and know it'll come out
 the same on different machines.
 Maybe numeric generator could use the bit-generator for some calculations?
 Main point of the Patel-specific RNG is that it shouldn't be *platform*
 specific. Want instruments created on one platform to sound much the same
 on another, and if the same seed gives different sets of random numbers
 depending on OS or architecture, that's no good.

-State machine type stuff, already started
 DONEish release/cut commands want attention; also want to make Patel able
 to start new songs (probably with different instruments/settings) after
 finishing the one it's played, and that's likely to need changes.

-Modulation!!!
 FM is done, but seems undetectable at low depth; probably need to allow for
 non-integer modulation frequencies too.
 AM is NOT done, but is related to envelopes which are.

-Store note->increment data in a table; have 2 or 3 tables, for different
 temperaments. Calculating increment for specific frequencies would be too
 tough to do with tables, but has half as much calculation as calculating
 for notes, so that can be done without anyway.
 [DONE, need to figure out if should have an octave-long table and
 shift the values based on the octave number, or one big table to describe
 all the notes;former saves about 280 bytes or so (important to cache),
 but requires calculating both octave and index into table- this too
 would be somewhat slow and benefit from a LUT!! However, that LUT could
 just be 84 bytes (each note:1 nybble for semitone, 1 nybble for octave)]

-Play routine, similar to that in the test harness; do ~64 samples or so
 into a buffer, pay attention to time in order to call "change state"
 type function (to play new line, change instruments, do new effects, etc)
 whilst going through those samples; write those samples to WAV file, then
 do some more :D This approach could probably be made to work with sound
 card output as well, except it'd sleep a bit whilst the buffers were
 emptying. Eh, ok, 64 samples sucks. How about... ~8192 samples?
 Eh, ISTR that big buffers caused problems in SDL-mixer when adding in
 sound-effects- they'd lag :(
 [DONE, but issues of whether to keep mixing in levels of channels that
 have stopped playing or cut them out remain- channels already deliberately
 remember where in the waveform they were playing, to resume at the same
 position in the next note, even if using a different instrument]

-Maybe if allowing sound-effects to be mixed in with music (like for game
 sound), they could be mixed-in with the buffered sound, *after* the
 music has been processed? This would probably give a bit more overhead,
 but would allow the program to produce music with less chance of underruns,
 and would give decent latency on effects :) [why is this under TODO?]

-Work out what sort of "graphical envelopes" to support
 [Preliminary data structures for them have been put in already, but they
 will be ditched and changed probably; question does remain how to arrange
 envelope data: Could have rate+target together for each element for good
 locality of reference, or could have all rates followed by all targets,
 for more compact data if they use different types (which they might well
 do). These are probably only relevant if there are more than a few
 elements. Also think about whether to store envelope data outside of
 instrument data to allow instrument structures to be more compact]

-Add interesting effects like panning, portamento, etc?
 Seeing the state machine implementation that's becoming obvious, such
 drawn-out effects seem far simpler to deal with :)

-Consider adding FM modulation, but remember chippiness! :D
 In fact, many chiptunes seem to have samples that have a shifting
 frequency, so maybe it's the thing to do.
 [Yes, I have, as it turned out to be fairly straightforward. Seems
 surprising now that it wasn't in the original idea]

-Make simple converter in Perl to output track files compatible with Patel's
 current parser (NB: Library version probably shouldn't have the built-in
 parser, except perhaps as a low-level optional item for programs to use
 for themselves, and then it's kind of irrelevant+superfluous); might make
 converter run from more intelligible track-style text files, might give
 it a built-in Perl/TK tracker program(!), or might make a GM midi parser!
 Main point is to have something to create tunes to try Patel out with, as
 otherwise it's just a toy.

-Deal with the question of signal biasing, which was intended from pretty
 much the beginning of the project and has structures etc to support it,
 but has never actually been made to effect the signals returned- largely
 because some of the biases would involve changing an odd-width signal to
 an even-width one, or deciding what values to overshoot/undershoot.

-That probably also needs me to work out whether the problem of signals that
 have higher amplitude in one direction *is* a problem or not; either way,
 it feels icky. I don't like the inconsistency.


 LATER
 =====
-Sort out the bit-depth stuff
-When in a decent state, decide upon an API and librarify!!


 EVENTUALLY
 ==========

-Replace use of libsndfile (which doesn't seem to cross-compile in a
 useable way) with a function for outputting WAV files directly.
-MMX version of processData() (mixer, etc)
-Make procedural module format to create libGameChip (would that be a
 replacement for Patel, or built on top?)
-Make midi renderer (either real-time or to wav)
 Requires decent understanding of GM, and a set of instruments to cover those
 in GM
-Make similar for use as ALSA sequencer
-Make simple interactive synth with NCurses interface? :)
 Hmm, this would need a rather small buffer though!!
