Using Git with SuperCollider

SuperColliderCompositions GitHub repository

I've set up a GitHub repository of the source code of some of the music I've been writing with SuperCollider.  I'll be posting walkthroughs of some of the code as those pieces get played on the Backtrace livestream.

I've been writing music with SC for about 5 years now, and my coding habits have evolved very little in that time.  They're also curiously out of sync with how I write code for web-based projects.  If I'm writing PHP or Ruby I set up a project in TextMate, where code is split up into many files and folders based on what aspect of the application they address (templates, database queries, etc).   I always have a corresponding git repository, even if it's just a local repo to store my revision history.   I use git to deploy code to servers (just do a git pull into the web directory).  But with Supercollider, I started out in 2007 writing compositions in single text file (synthdefs at the top, followed by sequences) and I still write code that way today.

I think part of the reason I developed this habit because of the lack of dev environments in SC.  I have the SC bundle for TextMate now so I can write code the same way I do for other projects - with a tree of multiple directories and code split into different files (some for synthdefs, some for sequences, some for utility functions).  But I think more than the lack of editor support, I have totally different motivations for writing when I'm doing code in SC.  When I'm doing a web project, I have some idea of what the completed code will be before I start writing - I'm given a set of requirements (or I have my own vision for the project) before I start, and I code to that vision.   With music in SC I rarely start out with an idea of what the final piece will sound like - the act of coding is a kind of improvisation or iterative process.  I write some code, play it, and when it's interesting enough, I record some to disk, then rename the file (and as you can see in the git repo I posted, I have dozens of files that are named by the date I when was working on that file).  Since SC is such a concise language, even complex pieces rarely involve more than 200 or 300 lines of code, so they're easy enough to manage as single text files.  I've thought of moving to a different client language like Ruby which would allow better integration with the web and the rest of my dev process, but so much of my code relies on super concise language constructs like array adverbs, and in Ruby you just can't quite say something like

(64 * (4..10).nthPrime *.x (2**(0..5)))

for example, to generate an array of frequencies based on the prime numbered overtones the fundamental pitch 64 hz from 11 to 31 across 6 octaves.  (Incidentally, with SC you could write entire LaMonte Young compositions in fewer characters than their own titles).

There's also the matter of when a piece is "done".  When building web apps there's obvious points to commit and deploy - some functional component works, so you do a commit, and when you have enough features commited, then you deploy those commits to a server.  With music, when do you "commit changes"?  It's more intuitive than objective - if I like what I'm hearing as I write, I'll commit the code, but if I'm using a lot of environment variables or higher-order functions, that code may not actually represent a blueprint of the sounds being played with the same 1:1 correspondence that a traditional score (or MIDI file) gives you.  What I need is a kind of "commit snapshot" function that would commit the code and the contents of all of the environment variables at that moment - and that's really more of a "save content to database" action in my mind than a "commit code to repository" action.

What's the SC equivalent of "deploying"?  One of the reasons why I've set up the Backtrace Livestream   is to have a space for the "deploy to production" moment in my workflow (also, one of these days I should unpack just how much my own thinking about music is structured by software dev practices).  Most of the music I've been composing in the last 5 years is open-ended algorithmic stuff, so even when I do create recordings, they're not a realization of a composition as much as a document of a moment.  And even still many of them are hours long, and while disk space is cheap, at that scale (~100 mb per recording) the cost just to stash them on a virtual server (let alone in SoundCloud) does add up.    Having whatever I'm working on running in a live channel maps more closely to how I intend the music to be heard.  It also let's me not have to worry about the whole "how do you perform deterministic algorithmic digital music" question - the sounds are available to anyone with internet access, and there's no beginning or end to them.

In a sense, everything I've written in SC has been variations on a single theme. I'm not sure how doing commits to a single file with a revision history will work with my process.  Often, I'll keep code for the last 5 or 10 revisions of a piece open and switch out certain components (a harmonizer function or a sequencer function) to see how they sound - maybe some days I'm more inspired to tweak the balance of sounds in the spectrum, and other days I'm more inspired to come up with interesting rhythms.  If I move to git, I'm starting to think that I might actually start totally reconsidering how I think of my code - seeing most of the musical details as data instead of code.  Unfortunately SC doesn't have any native capabilities for saving to databases, though there is a JSON quark I think so I could set up a bridge with something like MongoDB or Redis and a simple Ruby app.  Which is a whole other topic.