Revision as of 17:07, 21 July 2006 by Amisra
- we document things as much as possible, including screenshots, brief videos, audio examples, and didactic um sampleprojects. Obviously having good documentation is essential. chuckdoc.
- make examples, maybe dedicating a page for each, and also make a separate page to list the examples.
- keep fixing bugs [...]
- raw sound control
- so there are no other bugs that need fixing? um good
- code cleanup, refactor if beneficial for long time [ui_analysis]
- refactor the build tree (probably combine treesynth/ts/, v1/, and ui/) [done]
- rename files add GPL headers [done]
Not necessarily before
- finish defining and implementing the taps API in chuck
- sample rate flexibility
- might as well restructure the treesynth logistics somehow... [august]
- start PR (post to the major lists: music-dsp, music-ir, etc.)
- internal release, with presentation to woolworth dwellers
- keep adding features, especially those on research agenda
- keep working with composers
SOMETIME BEFORE ICMC
- release 1.0!!!
- make a video tutorial
- massive PR (music-dsp, music-ir, linux-audio-*, microsound, and other experimental music lists, get the composers to help us publicize) (linux. right.)
ICMC and beyond
- (someone's out of control)
- killer presentation and continue PR
- start supporting the user base, which should be giving us feedback to help improve the system/interface etc. (remind any users that this is the real world where they must fend for themselves.)
- give presentations in local region (NYU, Columbia, Penn, PSU, dorkbot)
- just the beginning!