Among all of the things that I have learned while working as a professional game dev, two very important things are 1) how to document and test bug fixes and 2) the importance of having a sane build process. I didn’t have a terribly good handle on either of these things when I first created Minim and as a result pushing out a release was a very painful process.
I’ve not always been good about keeping track of exactly which bugs I’ve fixed in a release, or which new features I’ve added. No longer! The past two days have seen verbose comments in my check-ins, which means I should be able to create a pretty exact changelog for the next release. Here’s my most recent check-in comment, to give you an idea of the kinds of things coming up:
- added freqToIndex method for converting a frequency to an index (duh)
- added getAverageCenterFrequency to get the center frequency of an average band from an index
- added forward(float, int) and forward(AudioBuffer,int) so an offset into the array of floats can be provided, in case a user has a large buffer they want to analyze only parts of.
- added setInputMixer(Mixer) so users can specify which Mixer to use when getting TargetDataLines
- added setOutputMixer(Mixer) so users can specify which Mixer to use when getting SourceDataLines
- added getServiceProvider() so that you can get a handle on the implementation being used by Minim.
- added createSample functions to get an AudioSample using a buffer(s) of floats.
- added getAudioSample(float, AudioFormat, int) and getAudioSample(float, float, AudioFormat, int) interface functions for requesting AudioSamples with buffers instead of from files.
Creating and uploading new JAR files is not the hard part of doing a release. No, the hard part is making sure all of my online examples are up-to-date and making sure the Manual reflects any additions or changes to the API. The biggest pain with the examples is that the directory structure that I use on the website does not match the local directory structure, so it’s not just an easy drag-and-drop. I have my examples set up as a subdirectory in my Processing sketch folder, but what actually gets uploaded to the website are the contents of the applet directory that is generated for each sketch when I export it. Man, I would love to know a way to tell Processing to export an applet to a location other than the sketch folder, because then I could export to a directory structure that is the same as what’s on the web.
In any event, that’s a pain, and I need to figure that out, but I also finally got around to creating a subversion repository for all of the example source files. This will at least make it easier for me to tell at a glace which sketches need to have applets re-exported and uploaded. Maybe I can even figure out how to create an automated process for this. But, one thing I had to do before I could commit all of the examples, was delete all of the applet directories. To do that, I googled around and found this totally helpful batch file:
FOR /F "tokens=*" %%G IN ('DIR /B /AD /S *.svn*') DO RMDIR /S /Q %%G
That particular code will delete all subdirectories that match the name “*.svn*” under the directory it is executed in. All I had to do was change the name to match to “applet”. It’s all really clearly explained in this forum post and worked liked a charm.
So, that’s at least one part of my build process that’s been sanitized (by which I mean: made sane)!