Wiki » History » Version 6
Version 5 (Redmine Admin, 2012-08-15 03:26 PM) → Version 6/14 (Redmine Admin, 2012-08-15 03:29 PM)
h1. Wiki
h2. Requirements
Third day of a three-day Software Carpentry bootcamp. Hours are 0900-1630 approx.
Should consist of working through introductory examples of audio processing techniques in Python, with small-group exercises for self-guided learning (helpers should be available in the room). Topics of interest should include reading audio data from files, synthesising signals and playing them, saving results back to audio files, simple filters, simple analysis techniques, and interactive plotting.
The material will need to follow from the subjects covered in the first two days of the bootcamp, such as unit testing and test-driven development, writing readable code, use of version control (we'll be using Mercurial in the bootcamp but the principles should mostly be general ones), selection and use of the most appropriate existing Python modules, etc.
h2. Related Links
* Bootcamp announcement: http://soundsoftware.ac.uk/york2012-bootcamp
* Software carpentry site: http://software-carpentry.org
* Audio Presentation (Becky's): http://software-carpentry.org/4_0/media/audio/
h2. Open questions
Can we come up with some good examples of simple audio processing problems that readily admit test-driven solutions? I think there will be a lot of interest in the question of how to apply automated testing and unit tests to audio research software.
Any examples we use will need to be simple enough to be worked through by people who have not necessarily worked on that specific aspect of audio programming before, but relevant enough that they give a clue about where to begin when working on their own problems subsequently.
* "Here":https://code.soundsoftware.ac.uk/projects/cepstral-pitchtracker/repository/entry/test/TestPeakInterpolator.cpp is an example with some basic unit tests for a peak interpolation method (in C++ with Boost) -- I think we can do better, but with what?
* Other things we talked about: testing FFTs using 4 points and known inputs/outputs (e.g. pure cosine); how to unit test e.g. a low-pass filter using expected outputs
h3. Things worth bearing in mind
* Validation vs. verification. Validation is what the evaluation section of a typical paper does -- tries to establish how well the method / model reflects reality. Verification is trying to establish whether the code implements the method or model at all. Unit That's what unit testing is a code verification tool. one tool for.
* That means, in a sense we aren't really testing the method. We're testing the implementation and the API. We have no expectation to test using "real-world" data. Tests should be small (and take next to no time to run).
h2. Requirements
Third day of a three-day Software Carpentry bootcamp. Hours are 0900-1630 approx.
Should consist of working through introductory examples of audio processing techniques in Python, with small-group exercises for self-guided learning (helpers should be available in the room). Topics of interest should include reading audio data from files, synthesising signals and playing them, saving results back to audio files, simple filters, simple analysis techniques, and interactive plotting.
The material will need to follow from the subjects covered in the first two days of the bootcamp, such as unit testing and test-driven development, writing readable code, use of version control (we'll be using Mercurial in the bootcamp but the principles should mostly be general ones), selection and use of the most appropriate existing Python modules, etc.
h2. Related Links
* Bootcamp announcement: http://soundsoftware.ac.uk/york2012-bootcamp
* Software carpentry site: http://software-carpentry.org
* Audio Presentation (Becky's): http://software-carpentry.org/4_0/media/audio/
h2. Open questions
Can we come up with some good examples of simple audio processing problems that readily admit test-driven solutions? I think there will be a lot of interest in the question of how to apply automated testing and unit tests to audio research software.
Any examples we use will need to be simple enough to be worked through by people who have not necessarily worked on that specific aspect of audio programming before, but relevant enough that they give a clue about where to begin when working on their own problems subsequently.
* "Here":https://code.soundsoftware.ac.uk/projects/cepstral-pitchtracker/repository/entry/test/TestPeakInterpolator.cpp is an example with some basic unit tests for a peak interpolation method (in C++ with Boost) -- I think we can do better, but with what?
* Other things we talked about: testing FFTs using 4 points and known inputs/outputs (e.g. pure cosine); how to unit test e.g. a low-pass filter using expected outputs
h3. Things worth bearing in mind
* Validation vs. verification. Validation is what the evaluation section of a typical paper does -- tries to establish how well the method / model reflects reality. Verification is trying to establish whether the code implements the method or model at all. Unit That's what unit testing is a code verification tool. one tool for.
* That means, in a sense we aren't really testing the method. We're testing the implementation and the API. We have no expectation to test using "real-world" data. Tests should be small (and take next to no time to run).