Projects from the Mind Vault
Today I realized that I'm lonely. It's a kind of loneliness that comes from doing lots of projects, but not sharing them with the world. I find myself locked in my head in a sort of Mind Vault. At the moment, I am working on about half a dozen personal projects relating to computer music and digital art. These projects excite me greatly, and have kept me busy enough in my mostly solitary lifestyle.
Fortunately, this type of loneliness is easily fixable. I've decided that it's about time I write these ideas down in one place, rather than let them swim in my head. Some of these ideas are only ideas, and some of them have quite a bit of code already written out.
In no particular order, here are some of my projects and what they do:
Prop is a micro notation language for rhythm written using C, Flex, and Bison. Using the very simnple rules, one could build very complex and interesting rhythms based on proportions. Prop falls into the same category of tools as NRT in that it is a text filter that makes more meaningful text for compositional programs like Csound. This program is basically functional, and I even have an unfinished secret page for it explaining some of the rules. I just haven't found a moment to document it properly (There are pretty pictures!)
LSamp is a lightweight sampler/archive format that errs on the side of being a little bit too lightweight. I initially came up with this idea because I wanted a way to store multiple audio samples in a monolithic format, and I found myself not really liking all the baggage attached. Since I had very specific ideas for what I wanted in a sampler format, I figured it would be quicker and easier to come up with my own system rather than try to stumble through what already existed.
Most of LSamp is inspired by TinyCDB. Like TinyCDB, LSamp is designed with a some very firm limitations (samplerate is not specified, only 1-channel files, only 24-bit, 4 gig file limit, etc). These limitations help keep things simpler for the machine. Some other day, I may come up with tools to use with LSamp should these handicaps decide to bite me in the ass later.
I believe this format will help encourage me to write more sample-based compositions and to be more proactive about using sounds I make on my field recorder. I also have high hopes that I'll be able to convert many of the Renoise sliced breakbeat files that I have on my computer into an easily maintainable lsamp format.
It's been almost a year since I've touched SoundPipe, and it was a great way for me to learn about using Lua C API and libsndfile. Since then, I've learned quite a bit about software design. In all honesty, the current SoundPipe codebase is sloppy. It's full of memory leaks. The Csound opcode ports are hacked together. The Lua code deviates to far away from the C code when really Lua should have only acted as a wrapper. There is no easy way to add new effects to SoundPipe.
I've been very tempted to blow up the current codebase and start from scratch and redesign SoundPipe with more defined goals from the start. I can definitely imaging being able to link this with all my other projects that I'm working on.
I simply can't forget about Brian, which started out as a pi-powered twitter bot that write little musical doodles. It was a very satisfying project, but my ideas outgrew the initial concept. The language (Ruby) wasn't fast enough, and it wasn't designed for the scale I had in mind. Brian ultimately stems from the idea that databases can be used to create music. Brian is a composer, and you are it's muse. You (the human), supply the Brian with snippets of musical data and possibilities to organize this data. and in turn, Brian treats this as inspiration for a composition. Over time, this data set will grow, and so will the complexity of the pieces Brian produces. It's a composition that keeps on composing!
I have a very strong interest in audio-visual music, and hope to someday be able create some of it myself. Realtime visuals were interesting to me, so naturally I gravitated towards processing. Processing did not run well on my old hardware, so I looked towards OpenFrameWorks. OFX was so frustrating to install on Linux and felt quite bloated to me. I just couldn't get myself to face the dependency hell, having to work in C++, AND being forced to learn a new IDE. Unsatisfied with what was available, I looked for a simple way to generate video for my music. Slicer was born. Slicer uses the really Cairo graphics library to generate many pictures that can be sequenced together using a program like ffmpeg. It's also has a csound score-like input file that can be used to sync audio events to picture. An example of this can be found here.
This code is pretty early on in development, but it works. My goal is to make Slicer look a little bit more like processing, and to write a piece of music with it that's more than 2 minutes long.
iCsnd is basically going to be my stab at using csound to do live coding in a performance setting. A little while back, I made a proof-of-concept video, but I'm pretty much going to rewrite everything to make it more efficient and portable. Some things are still up in the air, but I really want to see how I can use and abuse Csound's orchestra macros to create a very terse syntax geared for live coding.