UniAudio Development

This document is used to collect ideas about what has to change to start with UniAudio development again. This is by no means a complete document, so please help to finish it!

How to improve development

• Always try to make the audio hardware available to the developer or have a tester you can trust
  • Usually, it does not cost that much to purchase a sound card
    • Especially compared to the actual money that was spend on the developer!
  • If the card is not onboard, we should try to make it available to the developer
  • If not, we have to find a tester that helps the developer
  • If there is no tester, and the developer has no hardware, than we should not work on that
• Create a document that describes in full detail what a tester has to do and how
  • There are various ways in which UniAudio outputs usefull information, those have to be listed and explained
• Record user and tester reports in an "experience database" so the developer(s) can relate changes to effects more easily--also at later points for previous versions
• We need clear milestones
• Have a test plan for every major release
  • This can only work if we have a number of testers for UniAudio
  • It would be nice to have a list of "tested" vs. "untested" hardware, not just a list of what should work
• Standardize the build environment with the help of Christian Langanke
• Make it easier for testers and users to find appropriate versions
  • Follow a strict version numbering scheme
  • Record changes, preferably in "non-developer speak"
• Document the Uniaud API so other developers can put it to use
• have more then one developer on the project (less dependency, multiple eyes on the same problems, fall back, knowledge exchange)

How to raise money

• still empty