Execution Models

The Old Way

The old Boodler ran as a simple non-interactive process. You started it, it generated sound, and it ended (either because the soundscape finished or because you killed it).

You could extend this with the messaging protocol. You would run Boodler as above, but also run a separate process which would control Boodler (by sending messages). This is how Leash worked; same for the soundboard.php extension. (See http://eblong.com/zarf/boodler/aux.html.)

The New Ways

Boodler 2.0 will still work with the old models. However, the usual way of running it will be as a GUI application. You will run the app, make a soundscape selection, and hit "Play".

(Technically this will still consist of two processes, a player and a controller. However, the controller will start the player automatically; it will be invisible to the user.)

There are alternatives beyond these, as well.

• A background application that works as a self-contained web server. (Same player as above, but with a different controller, built on CherryPy or something similar.) You would run it as a daemon, and then browse its web pages to select soundscapes.