Difference between revisions of "Taps Release"

From CSWiki
Jump to: navigation, search
m
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
==NOW==
+
==Before release==
* we start documenting things as much as possible, including
+
* we document things as much as possible, including screenshots, brief videos, audio examples, and didactic um sampleprojects.  Obviously having good documentation is essential. chuckdoc.
screenshots, brief videos, audio examples, and didactic um sample
+
* make examples, maybe dedicating a page for each, and also make a separate page to list the examples.
projects.  Obviously having good documentation is essential.
+
* keep fixing bugs [...]
* post link to mailing list (when it's ready, probably tomorrow)
+
** pv
* after we hear back from SIGGRAPH and ICMC, we post the pdf (probably
+
** raw sound control
pending acceptance from SIGGRAPH)
+
** so there are no other bugs that ''need'' fixing? um good
* make examples, maybe dedicating a page for each, and also make a
+
* code cleanup, refactor if beneficial for long time [ui_analysis]
separate page to list the examples.
+
* refactor the build tree (probably combine treesynth/ts/, v1/, and ui/) [done]
 +
* rename files add GPL headers [done]
  
==MAY==
+
==Not necessarily before==
* refactor the build tree (probably combine treesynth/ts/, v1/, and ui/)
+
* finish defining and implementing the taps API in chuck  
* rename files add GPL headers
+
* sample rate flexibility
* keep fixing bugs
+
* might as well restructure the treesynth logistics somehow... [august]
* finish defining and implementing the taps API in chuck
 
 
* start PR (post to the major lists: music-dsp, music-ir, etc.)
 
* start PR (post to the major lists: music-dsp, music-ir, etc.)
 
* internal release, with presentation to woolworth dwellers
 
* internal release, with presentation to woolworth dwellers
 
==SUMMER==
 
* code cleanup, refactor if beneficial for long time
 
 
* keep adding features, especially those on research agenda
 
* keep adding features, especially those on research agenda
* keep working with composers to get them irrevocably addicted
+
* keep working with composers
  
 
==SOMETIME BEFORE ICMC==
 
==SOMETIME BEFORE ICMC==
* release 1.0!!!
+
* release 1.0!!!  
 
* make a video tutorial
 
* make a video tutorial
* massive PR (music-dsp, music-ir, linux-audio-*, microsound, and other
+
* massive PR (music-dsp, music-ir, linux-audio-*, microsound, and other experimental music lists, get the composers to help us publicize) (linux. right.)
experimental music lists, get the composers to help us publicize)
 
  
 
==ICMC and beyond==
 
==ICMC and beyond==
 +
* (someone's out of control)
 
* killer presentation and continue PR
 
* killer presentation and continue PR
* start supporting the user base, which should be giving us feedback to
+
* 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.)
help improve the system/interface etc.
 
 
* give presentations in local region (NYU, Columbia, Penn, PSU, dorkbot)
 
* give presentations in local region (NYU, Columbia, Penn, PSU, dorkbot)
 +
 
* just the beginning!
 
* just the beginning!

Latest revision as of 01:06, 4 August 2006

Before release

  • 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 [...]
    • pv
    • 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!