The master plan (sort of)
========================

0.3.x
-----

First, focus on fixing bugs and improving the mixdown engine.
Correctness and clarity are more important than performance, but make
sure there aren't any situations which cause pathological behavior.
Use sensible arbitrary limits and err on the side of small (users can
always redefine and recompile if their needs vary, and it can be made
a configure option if it's used extensively).  The only performance
feature that must work it's way in is a global polyphony limit.

[update, 2004-06-16: it turns out that having both a global polyphony
limit and a per-patch polyphony limit carries with it some daunting
subtleties.  Seeing as how Fruity Loops doesn't do things this way, I
get the impression it would be very difficult to do properly.  I have
ideas for other cheap but effective optimizations.]

We need portamento.  Rather, I desperately want portamento.  We shall
have portamento.

Further, the file writing system needs to be updated to account for
the new parameters, and probably needs a general overhaul.

0.4.x
-----

Create a new sample browser and generally improve the GUI.  All
controls should have greater precision, and volume needs to work
logarithmically.  Chrome and glass isn't important at this point,
focus on functionality.

0.5.x
-----

Implement the rest of the midi standard, and provide a graphical way
to bind controls to midi messages, preferably with a "learning"
feature.

Create a messaging system, probably just expanding on the one the mixer
already has, so that the gui sends messages whenever it wants to
change patch parameters, rather than doing that instantly.

Change the patch-display part of the interface to update itself
periodically by hooking into the main loop of gtk.  This way, 
midi automation that it receives will be reflected in the controls.

Lastly, make sure that messages received via midi don't permanently
change the values the user has set for the parameters.  The parameters
the user set should be the parameters that get saved, not necessarily
what the parameters are currently running at.  When a sync start or
stop is received, the parameters should revert to the user defined
state.  Create a button or menu option to manually invoke this action.

0.6.x
-----

Go for a jack only approach so that every instrument has its own port.
Test session management with LASH intensively, because being able to
hookup seq24 to Specimen, feed it through jack-rack, and record it all
in ardour will be uber-schweet.

0.7.x
-----

Remove arbitrary limits on polyphony and number of patches.  The user
should be able to add and remove patches in whatever numbers they see
fit.  There should be a configuration dialog to let the user set the
global and per-patch polyphony limits.

Also, add the ability to fine-tune the quality/performance tradeoff.
For example, the user should be able to select between linear and
cubic interpolation for the pitch scaling and LFO rendering.

0.8.x
-----

Make sure all existing features are complete.  ADSRs should also have
a delay and hold value and adjustable tension, per-voice LFOs
should have a delay value as well, pitch should be a modulatable
parameter and there should be coarse and fine controls for it, etc.

No *additional* features are going in, however.  For example, if a 32
step sequencer hasn't worked its way in yet, it's not getting in for
this phase at all.

Once everything is correct and complete, profile and optimize like a
maniac.  Only worry about bottlenecks, not general program stuff (it's
C, for chrissakes), unless something egregiously stupid is being done.

Anytime optimization results in obfuscation, comment *liberaly*.  The
engine is not done yet, and future expansion should not be sacrificed
because you were too lazy to comment.  If something is extraordinarily
subtle, write a doc file on it.  But every obfuscated optimization
*must* be documented.

0.9.x
-----

Work on a full-blown chrome and glass gui (although not in a retarded
way).  This should be done really really *really* carefully, and it
the user should be able to turn it off if they don't like it.

Take your time.

1.0.0
-----

Party like it's 1999.

