Australians making music with computer code
abc.net.au
abc.net.au
His PhD thesis about it (2018) is worth reading for anyone interested in live programming of any sort, music or otherwise: https://openresearch-repository.anu.edu.au/handle/1885/14460...
But I was impressed, and envied the processing power. However, digital musical interfaces are really what inspired me to code music in the first place, the idea of building them (which I do now).
I actually installed and tried extempore, and that almost got me into emacs, b/c the author had integrated it. Smdh. Luckily, I abandoned both, and have used vim ever since. I had looked at all the weird code music editor systems, deemed extempore the best, but ultimately I had to go raw and work my way up.
Earlier this year I stumbled onto Hundred Rabbits, which happened to have recently released ORCA (described as "an open-source visual programming language, designed to create procedural sequencers on the fly, and control other applications.")
At the time I didn't really know what that live-coding was a thing in terms of musical performance and just invented my own explanation for what they must mean and intend it for.
About a month ago I stumbled onto a reference to algorave, and then looked up a short documentary, in which I saw a few quick frames of someone doing a live show with ORCA (and, of course, encountered the term live-coding).
I guess it's a little bit more like a puzzle than some of the other languages/environments, but I like that it's possible to directly visually enjoy an orca program operating in the way you can't with the others I've seen (without generative visualizers of some sort...)
Here’s one of my fave public PureData patches, even though it’s dated. Generative dubstep that builds towards a drop that is triggered when you hit the drop button.
huh, why do you think that? https://github.com/pure-data/pure-data
Maybe you've been thinking about Pd extended - which is indeed unmaintained. There is a kind of successor called PurrData, but it's not 100% compatible with Pd Vanilla.
BTW, Pd 0.50 will probably be released in a couple of weeks (I'm a regular contributor)
Fluxus (https://www.pawfal.org/fluxus/) with scheme
Tidal Cycles (https://tidalcycles.org/index.php/Welcome) with Haskell
In comparison to other common musical vlangs (Pd, Max, etc), it offers a visual syntax for loops, triggers and conditions and is time-centric instead of dataflow-centric (so, better for making shows & songs than making instruments).
I think I'd invoke Sturgeon's law instead?
They either have a very shallow understanding ("I made an image" = "I made art"; "I played some samples in a browser or trained a GAN" = "I made music") or they have an academic misunderstanding, based on a decent technical understanding of the grammars of the medium, but limited insight into how creative originators can use grammars expressively.
There are exceptions, especially in visuals, so you have a point about Sturgeon's Law. But there are still far too many people treating generative media as a technical exercise, and too few using them for impressive original creativity.
It's amazing that these tools exist, along with those that can operate them, so music can be generated via code, live, and it comes down to (your opinion on) whether or not these tools ever grow past the "research" phase that they're currently in right now. IMO the tools will continue to evolve until they are useful in the hands of "creative originators [that] can use grammars expressively".
There's a impassioned community building and refining the tools and tooling, and its my belief and opinion - we don't have to all agree - that the algorave tools will eventually get to a place that's useful for creatives, and into their hands. Then the music being generated becomes the attraction, instead of the coding tool being a gimmick of an attraction.
After all, what's a drum machine, but a clumsy, analog "for" loop?
Procedural art is both new, and it isn't.
There's already a reasonably rich (if still fairly new in the sweep of art history) tradition of procedural art within the broader category of conceptual art. Some simple, accessible examples are Raymond Queneau's Cent mille milliards de poèmes, Sol LeWitt's line drawings, and Yoko Ono's Grapefruit.
These aren't quite procedural in the sense you mean, but they are instructions designed to produce art when compiled and/or executed. They (along with many other examples) shatter traditional-art assumptions more profoundly and thoroughly (well, I think so...) than the cubists, dadaists, and abstract expressionists. They fully-realize conceptual art. If a natural reaction to Duchamp's readymades or a Pollock painting is an exasperated but I/my kid could do that, these works hand art-observers the blueprint and call their bluff.
They foreground the gaps between the concept/idea of a piece, our interpretation of the idea, any given instantiation of the idea, and our experience of any instantiation. They highlight the difference between the traditional roles of the artist-as-thinker, the artist-as-craftsman/technician, and observer-as-interpreter--at the same time as they invite (or even demand) all parties to cross and blur roles. They expose the absurdity of the cults of the Author and the Original Object in a way that foreshadows what digital re-/production has forced most creative spheres to reckon with.
With this as a lens, it's possible to expand the family tree. Composed sheet music (most purely if a band/orchestra/choir interprets it from the instructions without listening to how it's "supposed" to sound) smells like procedural art to me. Screenplays and stage-plays (which are, of course, scripts) have similar features. A decent slice of performance art--even if not openly published as one--can still be distilled to a repeatable set of instructions.
Maybe it's hair-splitting, but from this perspective I see procedural art as a fairly rich tradition full of artists with a good feel for their media and the broad arc of their traditions. From here, I think it's easier to see modern-computer-aided procedural/generative art as a somewhat natural outgrowth of existing traditions--intersected with new technologies that I don't think we've caught up with yet.
I'll artificially cut myself off here; I have too many thoughts on what the hurdles are to put a bow on. In short: it seems fair to say computer-aided procedural art(s) are immature and have a skewed technician:artist ratio, but I think it feels about right given the sheer amount of work+play+interplay that it takes to establish radically new creative practices. A significant fraction of computational-creatives are still hand-rolling their own toolchains. I'm not even sure the sun has risen.
except when these scripts are interpreted, they do not lack performance ;-)
I am myself mostly familiar with visual generative and algorithmic art. I recently looked up the difference between these two and it's somewhat relevant:
Generative art is when an autonomous system that is not the artist takes part in or is used for the creation. Usually these are people with an art background. But very often, the art doesn't look that intriguing visually, because that is mostly carried by the concept of how it was made.
For instance. You can hook up a plant to an Arduino and some motors that control a brush. Now it's a painting plant. But the paintings will be rubbish. However, now you move the plant with sensors to one coast, and the motor control paintbrush setup 5000mi away on the other coast. Now there's an extra layer of depth to the piece, call it "non-local distributed agent control" or something. The painting will still be rubbish, but now there's something extra cool to the story/process, which is part of generative art.
This is why I very much dislike peopling calling their work "Untitled 2736" with no other explanation. If you have the above thing, but you only see the display output painting titled "Plant Study 663" then what is the audience supposed to think about it? No you put a little plaque next to it with the story of what you did, at least. I was in MoMa NYC years ago and it didn't do this, so I really only enjoyed the pieces that I recognized from being famous, or the ones that happened to look pretty. Other contemporary art museums that I visited did it much better and provided info, I had a much better time.
Point is, generative art is not always pretty or pleasing, because it doesn't specifically set out to be.
Algorithmic art seems to originate from the old school computer hobbyist scene, people using the computer to draw fractals, geometric shapes, etc. At first mostly because they were cool things you could make a computer do. Over time, this grew into more professional art as well.
Difference is, algorithmic art often sets out to be pretty. It's just that you use algorithms as brushes, preferably creating things that you couldn't come up with otherwise. I'm going to talk about these on the visual medium first because that's what I'm most familiar with.
Problem is, algorithmic art seems to have a bit of a soft divide between people with an art or design background that can somewhat code, and the computer coders with not too much design sensibility. The overlap is of course where the magic happens.
On the "art side", their work often looks very nice, but sometimes it lacks the algorithmic depth to take it to the next level, or come up with something original. What I see often is that a specific routine, say a cool wiggly way to draw a line (instead of a boring regular line), gets used over and over again in different works that use lines. It's a bit like you made a custom photoshop brush. What you sometimes get is an algorithmic work that is the combination of a bunch of "shallow" algorithms, but nothing really "new". It's difficult because you really need a solid math or computational science background.
On the "code side", you get all these toy examples of amazing algorithms. But their creations are picked to showcase as many modes of operation. And the colours will be white/black/blue/red. Or it will be rainbow puke because they used HSL/HSV too enthusiastically. The focus point of the work will be centered on the screen without much thought if it might look nicer any other way. Without too much background in traditional arts, they will not recognize a known path and how to execute it well (because history) or at least choose not to. Say what you made, just happens to remind a bit of Gustav Klimt. Maybe there were random colours and some happened to be shades of gold. Now you can choose: will you try and incorporate other elements of Klimt's style, or perhaps some Jugendstil aesthetics, to really nail it down. Or is that exactly not what you want and you recognize it so you can steer away from it.
Please note that all what I just wrote is very subjective to my understanding of generative and algorithmic art (corrections are very welcome). Also the "typical" examples I stated are of course caricatures to demonstrate a point. Most people will be a more moderate mixture of these.
Finally, about the musical examples in the article, I'm getting a similar vibe. I can't really say if it's the "code" or the "art" side doing this. What I'm hearing in especially the melodies is my own first experiences trying to write a random music generator. It's what you get if you pick notes randomly from a chord or a scale. Broadly, it doesn't take in enough context from itself and the rest of the music. The rhythmical aspect of melody, the importance of accent notes and phrase-ending notes, are usually ignored. Also larger structures like ABAC are constraints that actually add depth. But picking notes randomly from a chord or scale is a one-liner and thus great for live coding. Unfortunately the naive approach will always have this vibe of "the notes are not wrong, but they are very random" and different melodies generated will blend into each other because they are formed of the same mush.
Again, very very subjective opinions, and I'd love to hear how others see these things :)
Kindohm - https://www.youtube.com/watch?v=RiEq_h5UQJM Renick Bell - https://www.youtube.com/watch?v=6pks_BSqHB0 Algobabez - https://www.youtube.com/watch?v=2GTN8ELL75g Sebastian Camens - https://www.youtube.com/watch?v=Zu4dHW04W9Y
Both start silent while he types the setup code. The first has a visual aspect, the second only has the code displayed.
see snd editor, common lisp music
in the late 80s/early 90s, adding a processing core to a lisp/scheme was probably the easiest way to bootstrap an interactive/interpreted environment, and also give you the language features to design specialized syntax for your music language
Can't get my head around lisp/clojure.
Many live coding environments use SuperCollider as the engine (Sonic Pi, Overtone, TidalCycles), which while not as old as Csound is over 20 years old so there’s plenty of building on existing systems going on.
Departures from Csound and SuperCollider are also necessary for many artistic and technical reasons, and the live coding community welcomes the diversity of available systems and the increasing diversity of the systems creators themselves.