Something fascinating about seeing a 'score' for generative music written out as a sort of specification like that.
There's enough detail there that you can take those instructions and reimplement your own version of it, and you'll end up with essentially the same 'piece of music', but certainly a different interpretation of it. Because while the score lays out some details precisely, it leaves other choices less clear. What does 'all inversions' really mean when enumerating chords? Does it include open, spread voicings? What durations should we choose from for our random waveforms? How short is 'short' when deciding to repeat? And of course, what wave synths should you use, and how should you modulate them?
All those are similar to the decisions a traditional instrumentalist makes when interpreting a sheet music score for performance - here, a generative music coder can follow this 'score' and produce a program that represents their own interpretation of the piece.
Coding it up in Sonic Pi (https://sonic-pi.net/) was a fun exercise, and I feel like I was able to produce something along the lines of what the composer intended. It carries the same kind of mood that the recording in the video has. But it's my own 'performance' of the work, if that makes sense (even if it's actually Sonic Pi 'performing' it at runtime...)
All of which got me thinking about the relationship more generally between specification, and implementation. Considering different programmers' implementations of algorithms as individual 'performances' of scores from the overall design - and then thinking about developers building elements of a larger system architecture as individual performers working to deliver their part of the performance as part of a band or orchestra. Some groups, maybe they're directed by a conductor-architect; others maybe are improvisers, riffing off one another and occasionally stepping up to deliver a solo. And some are maybe solid session performers, showing up and delivering strong but unflashy performances to a producer's specification.
So overall, a nice meditative coding exercise for a Sunday afternoon, and a shift in perspective. Thanks for sharing it.
I think you really picked up what I was trying to do with the score, glad it came through.
I had some feedback from a art curator about a previous piece of work that I was going to show (this one in fact https://www.vitling.xyz/welcome-to-tech-talk/ ), and she didn't really understand what was going on. After explaining what was happening and how it all works she told me "I love it now; but you're hiding all the interesting parts from the audience".
One of the interesting parts about generative art is that the "work" I do is really the ruleset/algorithm, rather than the audio or visuals that come out of it, so I always want to find a way to show what's happening 'inside the box' so to speak. Source code can be nice, but only for those who can read it, and the core idea often gets lost in boilerplate and technical weirdness. That's where I got to the idea of writing a score for it instead, which just lays out the basic premise of what's going on - enough to understand that what's being played is generative but not so much as to get lost in the detail.
Thanks - it’s really just a magical choice of word you made. You could have posted the same explanation under the heading of ‘How it Works’ and it wouldn’t have had any of the same connotation for me. Calling it a ‘Score’ made something click.
I love how you've done this. It really is a musical score. Reminds me of Terry Riley's similarly "algorithmic" approach to describing how a piece of music is played.
What does 'all inversions' really mean when enumerating chords? Does it include open, spread voicings?
I think it usually just means: take the chord in its ‘root position’, and take inversions (that is, sort of (up to octaves) cyclic permutations) of it. So it would be leaving out lots of those more open, sparse voicings.
A basic c maj chord is c4 f4 g4. Inversions move bottom notes to the top, like f4 g4 c5, or g4 c5 f5. They significantly change the flavor of the chord.
Comments
Something fascinating about seeing a 'score' for generative music written out as a sort of specification like that.
There's enough detail there that you can take those instructions and reimplement your own version of it, and you'll end up with essentially the same 'piece of music', but certainly a different interpretation of it. Because while the score lays out some details precisely, it leaves other choices less clear. What does 'all inversions' really mean when enumerating chords? Does it include open, spread voicings? What durations should we choose from for our random waveforms? How short is 'short' when deciding to repeat? And of course, what wave synths should you use, and how should you modulate them?
All those are similar to the decisions a traditional instrumentalist makes when interpreting a sheet music score for performance - here, a generative music coder can follow this 'score' and produce a program that represents their own interpretation of the piece.
Coding it up in Sonic Pi (https://sonic-pi.net/) was a fun exercise, and I feel like I was able to produce something along the lines of what the composer intended. It carries the same kind of mood that the recording in the video has. But it's my own 'performance' of the work, if that makes sense (even if it's actually Sonic Pi 'performing' it at runtime...)
All of which got me thinking about the relationship more generally between specification, and implementation. Considering different programmers' implementations of algorithms as individual 'performances' of scores from the overall design - and then thinking about developers building elements of a larger system architecture as individual performers working to deliver their part of the performance as part of a band or orchestra. Some groups, maybe they're directed by a conductor-architect; others maybe are improvisers, riffing off one another and occasionally stepping up to deliver a solo. And some are maybe solid session performers, showing up and delivering strong but unflashy performances to a producer's specification.
So overall, a nice meditative coding exercise for a Sunday afternoon, and a shift in perspective. Thanks for sharing it.
I think you really picked up what I was trying to do with the score, glad it came through.
I had some feedback from a art curator about a previous piece of work that I was going to show (this one in fact https://www.vitling.xyz/welcome-to-tech-talk/ ), and she didn't really understand what was going on. After explaining what was happening and how it all works she told me "I love it now; but you're hiding all the interesting parts from the audience".
One of the interesting parts about generative art is that the "work" I do is really the ruleset/algorithm, rather than the audio or visuals that come out of it, so I always want to find a way to show what's happening 'inside the box' so to speak. Source code can be nice, but only for those who can read it, and the core idea often gets lost in boilerplate and technical weirdness. That's where I got to the idea of writing a score for it instead, which just lays out the basic premise of what's going on - enough to understand that what's being played is generative but not so much as to get lost in the detail.
Thanks - it’s really just a magical choice of word you made. You could have posted the same explanation under the heading of ‘How it Works’ and it wouldn’t have had any of the same connotation for me. Calling it a ‘Score’ made something click.
I love how you've done this. It really is a musical score. Reminds me of Terry Riley's similarly "algorithmic" approach to describing how a piece of music is played.
One of my favorite procedural visual artists has a similar vagueness to his specifications that leads to a nice variation each time a piece is recreated: https://www.sfmoma.org/artist/sol_lewitt/ https://massmoca.org/event/walldrawing305/
I think it usually just means: take the chord in its ‘root position’, and take inversions (that is, sort of (up to octaves) cyclic permutations) of it. So it would be leaving out lots of those more open, sparse voicings.
A basic c maj chord is c4 f4 g4. Inversions move bottom notes to the top, like f4 g4 c5, or g4 c5 f5. They significantly change the flavor of the chord.
Yes, those are 'closed' voicings of the basic inversions, though. What about f4 c5 g5? Still a C/F, but an open voicing.
I mentioned Sonic Pi in my post - it actually has a bunch of built in API support for this sort of thing.
Generating all the basic inversions of all those chords for all those root notes is as simple as:
'the_chord' gets set to arrays of midi notes corresponding to every inversion of every chord.Pretty sure that's a C sus4
Ha, true. Derp.
i thot it was c4 e4 g4?
It doesn't sound like there are open chords in there, just the ones where the notes follow each other immediately without any gaps.
Right. But that's what you glean from listening to the performance. Not what you can gather from reading the 'score'.