ANTAGONISE YRSELF!
Recently I have seen various blog posts from software developers that are coming from the perspective of 'I am an AI skeptic, but for [my own particular reason] I tried a project using [some AI code assistant] and it kind of worked. I hated that it kind of worked but I guess that's how it's goes'.
HERE is a good example from the legendary game developer Ron Gilbert (who made The Secret of Monkey Island series amongst other things). Gilbert makes no bones about his dislike of AI companies and AI as a concept. He thinks it is all entirely unethical, and though his opinion is that these LLMs can sometimes do correct and useful work in the specific domain of coding, he nevertheless concludes with a kind of bewilderment about why he would choose to de-skill himself by adopting the role of a middle manager dutifully correcting the AI's code instead of simply continuing to allow himself to enjoy the creative and rewarding act of programming.
Ron Gilbert and his Monkey Island video games brought me much joy over the years and I am in no way meaning to attack him for his AI experiment. I can see how it is useful to briefly engage with one of these chatbots on a subject where you are in fact an expert, because it so quickly demonstrates the ways in which the machine will generate plausible nonsense back at you. At the same time, I kind of hate that these sorts of blog posts seem to be popping up because I feel like cumulatively they encourage the idea that the creeping-death-scam-pyramid-scheme called 'AI' is inevitable in a way that I do not want to accept. And, in fact, still do not remotely believe, given the endless money it sets on fire, the lack of any revolutionary new output appearing and how the leaked Claude Code is so obviously bad even I can understand enough about why to laugh at it.
I don't think anybody reading this needs any more convincing of that though, so instead of more complaining about AI I have decided to do the opposite.
Because I do actually have a code-based project that I have so far not had the right combination of time and skills to get it off the ground. In terms of complexity, I imagine the code itself to be relatively simple, and I already have a rough design of the overall architecture of the software. I suspect with the right AI assistant I could prompt the whole thing into existence in a matter of hours, and I might even be just competent enough to then slowly weed out all the inevitable bugs and nonsense to get some kind of vibe-coded, hilariously inefficient, but technically-not-broken version of it up and running.
Obviously, I am not going to do that. Instead I am going to finally dive into the friction of learning how to do it all myself.
OBSTACLE ORIENTED MUSIC?
There's a line in Capitalist Realism where Mark Fisher complains:
Some students want Nietzsche in the same way that they want a hamburger; they fail to grasp - and the logic of the consumer system encourages this misapprehension - that the indigestibility, the difficulty is Nietzsche.
I'm pretty sure I've referenced this line somewhere on this website before, maybe even more than once, but whatevs: Fisher's point stands! And it is the point AI boosters always seem to miss - sometimes the friction is the thing! That painful act of dragging your brain upwards to some new understanding or skill, climbing a rickety scaffold of new chunks of knowledge, falling often, failing often, looking for new handholds when a particular overhang is simply too much... All of this is the point of the exercise.
There can be no shortcut to understanding that which can only be understood through a durational, experiential struggle. You literally have to do the thing.
Sure, if and when you eventually do become an expert, I can see the value in/seduction of being able to skip a lot of the preliminaries and get stuck straight into the good stuff. For example, during a recent conversation with an electronic musician friend, he was telling me all the ways he has streamlined his studio to make sure there is as little as possible getting in the way between the ideas in his head and capturing them on a computer. He has spent his career getting incredibly good at his chosen tools; he doesn't need to keep endlessly doing the hard work of learning new ones, he can simply use what he already knows how to wield. They fit the task at hand.
A valid approach, and one that I often pine for. But to my eternal frustration and occasional thankfulness, for better and worse my approach seems to be putting as many new obsctacles in between me and music-making as possible. WHY DO I DO THIS WHY WHY OH WHY CAN I NOT JUST LOAD UP ABLETON AND SMASH OUT SOME BREAKCORE I COULD DO THAT RIGHT NOW AND IT WOULD PROBABLY EVEN BE QUITE GOOD. I COULD JUST PLAY SOME PIANO, I COULD SCULPT SOME MIDI INTO SKITTERY BEATS IN 15 MINUTES WHY AM I LEARNING A NEW CODING LANGUAGE TO SLOWLY AND PAINFULLY RECREATE SOMETHING THAT ALREADY EXISTS SO IT CAN EXIST IN A SLIGHTLY DIFFERENT WAY AND WITHOUT USING COMMERICAL SOFTWARE? I COULD WRITE A NEW POLINSKI ALBUM IN THE TIME THIS WILL TAKE?? I COULD EVEN COME UP WITH SOME IDEAS FOR NEW 65 SONGS???
WHY?
Why.
OH WELL
For the last eleven days I have been learning a coding language called ChucK. I have bounced off this a few times over the last few years, but this time, after a lot of false starts, I have found my way in.
Wreckage_Eternal is an attempt to rebuild Wreckage Systems using open-source software. I am hosting the repository on codeberg HERE. Feel free to follow along if you like.
65LABS
It's at a very early stage. I am currently guessing at the low-level building blocks that I'll need to be able to recreate the more complicated systems. But I do have a draft version of one of the systems (Detext) up and running. It lacks the polish and production values of the version of Wreckage Systems that is currently streaming, which was made with Unity and Wwise, and it is even further away from the hi-fidelity Wreckage Systems Redux prototype that I built using Max a little while ago. Which is a pity, and the limits of the audio effects available inside ChucK may yet hamper the continuing of this project. BUT. While I do miss having a high quality reverb, as I saw somebody on the internet say the other day — in this looming era of all this smooth-edged, overly slick, uncanny AI slop, maybe scruffy, lo-fi production values are exactly what is needed to push back against it?
Once I have a stable sound engine in ChucK, I am considering integrating Godot (also open source), to provide visual output, and potentially be some kind of conductor/Wreckage Control, because I get a sense it'll be a lot easier to throw data around using the Godot editor than doing it all in ChucK code. (I've taken a few runs at doing the whole thing in Godot but its audio capabilities just aren't there yet.) But let's see how it goes.
CONCLUSIONS?
Nah, not yet. I'm just making it all up as I go. Fair warning though - if it starts seeming remotely plausible that this could be scaled up into an actual for-real Wreckage Systems rebuild, I'll feel duty-bound to shift the development blog over to the 65LABS Wreckage.Systems site.
So that's all for now. It's highly unlikely that anybody else will be able to get that repo to make any noise, but I get a sense that music-making/code-y people are a good percentage of the readership of this small website, so feel free to find me on Mastodon or ping me on the 65Discord if you wanna chat about it, I'd be happy to. ChucK is very mind-melty as a concept but if you manage to break through its barrier to entry it's quite a lot of fun! I mean, probably not as fun as turning off the computer, but still.
Bye for now.
Member discussion