27 Dec 2006
- Analogy 0.5.2 released, following migration of code from version 18 to version 19 of the PortAudio library. This change allows a single build of Analogy to interface with diverse audio hardware APIs (for instance with all of the MME, DirectX and ASIO drivers present on a Windows XP machine). See downloads
05 Dec 2006
- alpha release of analogy 0.5.1 code and Win32 binary. See downloads
10 Nov 2006
- New version of Csound (5.04) officially released. Downloads available here
13 Oct 2006
- Public concert premiere of pre-release version of Analogy in an excerpt performance of music for the silent film Metropolis, during the SoundPlay festival
, Toronto, Canada.
Analogy is a scene-based environment for the creation and performance of live electronics pieces, using Csound patches, VST plugins and an assortment of native DSP and GUI elements. Developed for the specific situation of live electronic accompaniments to silent films, Analogy is well-suited to a wide range of performance contexts, and especially to those involving an iterative, collaborative process between electronic sound artists and acoustic performers.
Although still in the alpha stage, Analogy has been successfully employed in a variety of work creation and concert situations. The software is released to the public under the terms of the GNU Public License (GPL). In a nutshell, this means that you are free to download, use, modify and distribute the software, provided that you pass that same privilege onto others.
The user navigates between different parts of the program using a simple tabbed interface. Generally speaking, each tab corresponds to a different stage or moment in the creative process:
The Inputs interface is used to configure audio inputs for live electronic processing. Each input can come from ADC hardware (i.e. from microphones, pickups, etc) or from a specially-named soundfile on disk. Among other things, this enables a type of deferred collaboration where live performers are present at one engagement and absent at another. The user can also control whether a given input is "monitored", i.e. routed directly to output in addition to being routed to various patches for processing:
The Setup interface is for controlling the relationship of a project to the hardware at (i.e. shortly before) performance time. In addition to selecting audio input, audio output, and MIDI devices, the user can insert Output Inserts between the projects' patches and the hardware. This is particularly useful for work with Ambisonics. A project can be spatialized to Ambisonic B-format without regard for the loudspeaker configuration in use - then, at performance time, the appropriate Ambisonic decoder can be quickly selected:
The Record interface controls which audio streams are saved to disk during performance. Each input is saved as a separate mono file. It is also possible to choose between recording the "undecoded" output (i.e. Ambisonic B-format) or the output of any Output Inserts (i.e. the Ambisonic signal as decoded and fed to a rig of 8 loudspeakers):
At performance time, the Perform window is used. The long horizontal meter measures CPU load. The row of controls below that consists of (from left to right) logarithmic (dB) audio input meters, a window containing messages from the software, and logarithmic output meters. Below this are the Scene controls. An Analogy project consists of any number of Scenes, each of which contains information about whether a given DSP patch is active, inactive, fading in, fading out, etc. This SceneList is traversed using the back and forward buttons. Below the Scene controls is a large panel where the GUI elements (dials, faders, text inputs, graphs, buttons) attached to active DSP patches appear:
Development and testing of Analogy is ongoing. Tasks earmarked for immediate attention include the implementation of a graphical editor for scenes and the DSP list, support for "live coding" and insertion of Csound patches, and "porting" the software to OS X (in theory, all of the code is cross-platform; in practice, some things will require fixing).
Comments, questions and offers of collaboration can be sent to [email: david (dot) ogborn (at) utoronto (dot) ca].