GUI
The goal for Boodler in the modern age: a GUI application that people can download, which will play soundscapes at the push of a button. The application will have the iTunes model: it will retrieve a list of soundscapes from http://boodler.org/, display them, allow the user to pick one, download the necessary data, and start playing.
(Not all of this functionality will appear right away; see the roadmap.)
To some extent, this is an old-fashioned goal. People these days like to see things work in a web browser. If you ask them to download an application, you've already lost 96% of your audience. (Ask me about Volity...) However, Boodler is not a good fit for a web browser.
- Boodler does a lot of audio mixing and pitch-shifting, which is not a common browser facility.
- All the soundscapes are in Python. Shifting to Javascript would mean not just porting the application, but throwing away the current soundscapes, and declaring that all future soundscapes will be Javascript.
(Footnote: Iron Python (for .NET) may resolve this conflict someday. For the moment, .NET is too encumbered and Mono is too obscure to rely on.)
Structure
The current plan is for the GUI app to be built on wxWidgets. It will actually constitute two Python processes:
- A GUI application, which starts up and manages...
- A Boodler sound layer.
The sound layer will be controlled through simple commands sent (via stdin) from the GUI layer. These commands will include volume changes, switching soundscapes, and so on. The GUI layer may sometimes kill and restart the sound layer (e.g., after installing a new version of a soundscape).
The two-layer model is good for security. The GUI layer will download soundscapes and store them in the collection, but it will never execute soundscape code. The sound layer will read and execute soundscapes, but it has no need to write files or do any network operations.
(This would be more reassuring if there were a way for Python to disavow capabilities like file-writing and network access. See security.)