A few months ago I investigated control languages for MIDI and OSC data as part of an arts research project. I thought it might be useful to share this work with anyone else interested in programming audio.
Currently I use Reaktor to create my own software instruments, sequences, audio control signals and music generators. But in this instance I require an open source and free product, so that any of my development can be easily shared. I require support for my primary operating system, Windows XP, butalso needed compatibility with LINUX and Mac OS X for the widest deployment possibilities. With these criteria in mind, I was ready to evaluate possible solutions.
In order not to get buried under hundreds of possibilities I decided to disallow graphical-only products. The reason is that I need fine-grained control and the ability to replicate objects programmatically. Reaktor and other graphics-based applications are deficient in this regard. Though you can easily group any number of functions as an "object", and subsequently duplicate these, you have a problem if you need to make a change. Rather than make a change to one object and have it reflected in all instances, all copies must be changed manually.
In other words I need an object-oriented environment, not just something that looks like objects but does not fully partake of the OOP paradigm.
My goal is to build a control system for a sound installation. This needs to process environmental data in real time, converting this to some sort of signal flow (MIDI, OSC, serial data stream). Hence any product that is not mature and stable enough to run for days unattended does not qualify. Efficiency is also a concern. The fewer system resources (RAM, drive space, processor speed) required, the better.
All of the products discussed in this series of articles meets these criteria unless otherwise noted. (Though I remark in passing that the stability and efficiency requirements are harder to pin down than the others.)
In addition, there were further criteria in the "nice to have" category.
The language should be powerful, expressive and easy to read. I am used to Python, which reads more or less like pseudo-code. Anything too abstruse now seems like a waste of time. Remembering that the end product is an aesthetic product, I do not want to use any tool that too severely shunts aside the artistic side of my creativity.
A strong user community with helpful documentation, examples, and so on helps a newbie not only get started but continue in the right direction without reinventing the wheel.
I investigated two broad classes of solutions. The first are specialised languages built especially for audio. The second are packages or libraries that give a general-purpose language strong abilities in this specific domain. Since my high-level language of choice is Python, I focused my attention on modules for that language. If I preferred Java or Lisp or Forth or some other language, there would be a myriad of additional solutions.
It turns out that there is some overlap between the two solution categories, since Python can be embedded in specialised tools or used as a higher-level control structure for same. (As it commonly is with Csound, for example.)
In the next article I will look at the specialised audio control languages.
I thank the Arts Council for their support in this research.
In other words I need an object-oriented environment, not just something that looks like objects but does not fully partake of the OOP paradigm.
My goal is to build a control system for a sound installation. This needs to process environmental data in real time, converting this to some sort of signal flow (MIDI, OSC, serial data stream). Hence any product that is not mature and stable enough to run for days unattended does not qualify. Efficiency is also a concern. The fewer system resources (RAM, drive space, processor speed) required, the better.
All of the products discussed in this series of articles meets these criteria unless otherwise noted. (Though I remark in passing that the stability and efficiency requirements are harder to pin down than the others.)
In addition, there were further criteria in the "nice to have" category.
The language should be powerful, expressive and easy to read. I am used to Python, which reads more or less like pseudo-code. Anything too abstruse now seems like a waste of time. Remembering that the end product is an aesthetic product, I do not want to use any tool that too severely shunts aside the artistic side of my creativity.
A strong user community with helpful documentation, examples, and so on helps a newbie not only get started but continue in the right direction without reinventing the wheel.
I investigated two broad classes of solutions. The first are specialised languages built especially for audio. The second are packages or libraries that give a general-purpose language strong abilities in this specific domain. Since my high-level language of choice is Python, I focused my attention on modules for that language. If I preferred Java or Lisp or Forth or some other language, there would be a myriad of additional solutions.
It turns out that there is some overlap between the two solution categories, since Python can be embedded in specialised tools or used as a higher-level control structure for same. (As it commonly is with Csound, for example.)
In the next article I will look at the specialised audio control languages.
I thank the Arts Council for their support in this research.
RELATED POSTS
No comments:
Post a Comment