-*- write-file-hooks: (time-stamp); time-stamp-format: "%04y-%02m-%02d %02H:%02M:%02S %Z" -*-

Time-stamp: <2001-03-04 14:25:35 PST>

 * Switch to non-paletted color, to better exploit high-depth displays

 * Create a separate thread for all the real work

 * Add option for taking using average or max of computed hues as the
   hue for all bands.  This will obsolete the new Average Intensity
   hue mode.

 * Check out onset detection algorithm in {Todd, N. P. McA. 1994, "The
   auditory `primal sketch': A multiscale model of rhythmic grouping,
   J. New Music Res. 23, 25-70.}

 * Add beat coloring option based on (to-be-written) clean-room GPL
   implementation of Eric Scheirer's beat detection algorithm.
   {Scheirer, Eric D. (1998).  Tempo and Beat Analysis of Acoustic
   Musical Signals J. Acoust. Soc. Am. 103:1 (Jan 1998), pp 588-601.} 
   http://sound.media.mit.edu/~eds/beat.pdf
   http://sound.media.mit.edu/~eds/beat/

 * Separate time smoothing weights for rising and falling

 * Make constants for onset coloring configurable

 * Make colors configurable

 * Allow user to set line thickness (lines per sample)

 * Add option to allow clicking on the window to make XMMS skip to the 
   audio that created that part of the visual.
     Pass 1: Undefined behavior when you click on data from another track
     Pass 2: Ignore clicks on other-track data
     Pass 3: Skip to the right track

 * Option to use gradient (1st difference) instead of raw data

 * Option to map one value to intensity and another to hue
     Examples: intesity = raw, hue = stereo (a current option)

               intensity = raw, hue = freq smoothed gradient.

               intensity = raw, hue = raw.  (gives colored peaks)

               intestity = raw, hue = freq smoothed time smoothed raw
               (so it's colored by continuity, with some room for pitch drift)

   It'd be neat to use multiple hue sources, like red for stereo and
   blue for positive gradient.  But this won't work for indexed-color
   displays.  The best solution I've thought of is to allocate colors
   in a divide-and-conquer order, so we get the most distinct colors
   before running out.  Then we can suck the palette dry and if we run
   out early, it won't be so bad (except for their other apps).

 * Allow multiple windows, each with different layout, data mapping, geometry,
   and color configurations.  (I think this would be great, but the
   config UI would be complicated, so I probably won't implement it.
   Anyone want to do it for me?)

 * Make a red-blue 3-d mode (need glasses)

