TODO

Features that boar is lacking, none of which are guaranteed to ever actually
be implemented. If you are interested in contributing to boar's codebase, these
may be good ideas to work on.

[YES] Revisit voice stealing and retriggering:
I suspect that note retriggering and voice stealing is slightly flawed. The
envelopes behave inconsistently when the same note is played in rapid
succession.

[YES] Env time in seconds:
Rather than having an arbitrary limit, express envelope time in seconds. May
complicate external MIDI control if such a thing ever moves beyond note on/off,
but this is not a priority. This is currently implemented, but is buggy with
long envelopes due to floating point resolution of phase. Unsure if it's worth
converting to double for extra long envelopes.

[YES] Band limiting adjustment:
All complex wave forms are band limited just below the aliasing limit, which
still might be too harmonically complex to actually sound good. Should have
a command that tells boar to read +/- wavetables from the default. This is
currently implemented, but only to mute harmonics, not augment them.

[YES] New parser:
Parser can be better. Maybe take ideas from boar-parser experiment repo.
 - Allow multiple args, some of which are optional.
 - Use real names for waves, etc instead of numbers
Other features, such as more oscs and better modulation routings, may come from
this.

[MAYBE] Faster random values:
Values returned by rand() may be unnecessarily high quality. Consider a more
basic solution for a performance boost.

[YES] Additional oscs, envs:
Allow an arbitary number of oscillators and envelopes, and allow the user to
define the manner in which they modulate one-another.

[MAYBE] Remove wavetables:
Get rid of all wavetables and associated logic. Only use Colin Wallace's
Chebyshev approximation of a sine [-π/π]:

float approxsin(float x) {
    float pi_major = (float)M_PI;
    float pi_minor = -0.00000008742278;
    float x2 = x*x;
    float p11 = 0.00000000013291342;
    float p9  = p11*x2 + -0.000000023317787;
    float p7  = p9*x2  + 0.0000025222919;
    float p5  = p7*x2  + -0.00017350505;
    float p3  = p5*x2  + 0.0066208798;
    float p1  = p3*x2  + -0.10132118;
    return (x - pi_major - pi_minor) * (x + pi_major + pi_minor) * p1 * x;
}

[MAYBE] Fixed point phase:
Use fixed point phase, which may be simpler for wavetables (but harder for
everything else).

[MAYBE] Use stack more:
Locate performance critical data structures and keep them in stack vs heap.

[YES] Info:
Running the info command (i), followed by a string, should return information
about the queried parameter to stderr. Like `i W'` would return the shape of
the modulator wave, etc.

[YES] Help:
A help (h) command followed by a command char could explain the purpose of
each command. 

[YES] Additional inputs:
The ability to assign parameters to modwheels, aftertouch, etc. The interface
for these devices would have to be generic, with an external program
converting their values into a proper boar command. Maybe two values could be 
read through mod (m/M) commands.