Failures
Overview
A curated selection of some projects I've done that are failures for one reason or another.
Failures happen when I try out an idea, and it doesn't work out. This is a very familiar thing for me. Luckily, there has yet to be a failure for me that has been a net negative. Nearly always there is something to learn from.
Failures in Monolith
monolith is full of bad ideas, so this is an easy one to start with. I throw a lot of things in that project to see what sticks. In particular, the many pages that I have made for it.
line16
line16 was a line sequencer I made for monome and arc that could produce curves and lines to use as control signals in patches. This ended being difficult to use in musically settings. Because the line durations where all managed internally, it was very difficult to make this program "play well" with others. I also made it so the input values were all normalized intensities, seemed great and made a lot of sense for the interface, but that backfired.
Line16 was a very ambitious page in Monolith to make, full of animation challenges that I had to think about and solve. Line16 was a great step in the right direction for me with my thoughts about gesture and continuous control, and helped give me insight into a new line sequencer I am attempting to build..
trig
trig is/was a rhythmic computer. The idea is basically build a clock signal generator that was a toy VM, programmable via the grid interface.
Cool concept in theory, except the intersection between what is interesting for a programmer and what is interesting musically is very small. I'm hoping I can make more of an interesting connection at some point, but I've been underwhelmed by the results so far.
Failures in Sporth
Sporth In General
I've outgrown Sporth. This is hard for me to say because of how much time and effort I put into it, but I have. It didn't work too great on mobile, and you couldn't easily extend the language without recompiling the entire codebase.
So! I got to work trying to re-imagine something a little bit better. I first started by separating the underlying engine with the language more. This new engine would be called patchwerk. And since I already happened to have a general-purpose stack based language lying around, it was trivial to merge the two together to make something very Sporth-y, while being more efficient and flexible.
Prop
prop was a proportional rhythmic notation system I wrote that would produce trigger signals. I made two implementations of it, one of which lies in Soundpipe (mostly to be used in Sporth).
The big issue it has is that it uses it's own internal timing, which means inevitable clock drift if it tries to play with others. This inability to interact with other things stunted the growth right there.
Prop ended up being very musically satisfying to use, so my hope is to one day re-explore these ideas. Maybe in gest? That's the plan for now, at least.
Lsys
lsys was an rhythmic L-system notation language I wrote inside of Sporth. It turns out generating rhythmic sequences from L-Systems aren't as interesting as I hoped they'd be.
The lesson I learned here is: don't let your eyes trick your ears. There are a lot of very interesting things in computer graphics that look flashy and cool in the visual domain, that end up being lackluster when translated to the audio domain.
PolySporth
polysporth was a weird attempt at getting polyphony in Sporth, using Scheme. It wasn't fully thought out, and it just ended up being a mess. I did get quite familiar with s7 scheme, then tinyscheme. I also learned not to underestimate the difficulties of polyphony. And as it so happens, I realized that getting polyphony working in sporth wasn't worth the trouble.
Spigot
Spigot was a set of GUI interfaces I wrote to control Sporth. These failed with the classic issue of too small to be useful with no room for growth.
Libline
libline was my first attempt at building a library for generating audio-rate line segments for use in automation curves. Similar to prop, libline managed time internally and had clock drift issues which made things fall out of sync very quickly.
Steps in the right direction, and like Prop, something I hope to explore more in gest.
Voc
I spent some time porting Pink Trombone to ANSI C in a project called voc. I was pleased with the sounding results, and I even managed to grok some of how Pink Trombone worked. But this was my first literate program. The literate style only made things more confusing to read, not less. Had I done things differently, I would have tried porting it all to C first before adapting it as a literate program.
I'm hoping to take a second stab at this at some point. But for now, I've taken small stabs by porting portions of Voc into sndkit components tract and glottis.
Runt
Runt set out to do one thing, failed, and now is being used for something else.
If I am recalling this correctly, I think I wrote Runt as a thing to work with polysporth, of all things! At the time, I was fighting with the garbage collector in the scheme implementation I was using (mostly me accidentally misusing stuff probably), and wanted something that wouldn't suddenly decide to randomly delete things. I think I wanted Runt to be a thing I could metaprogram from Scheme? It really wasn't a fully thought out idea.
Anyways, I had plans for making Runt this nice little forth-like general purpose scripting language that could do things like define words and procedures and stuff, and that would also be very easy to extend via dynamically loaded plugins. None of these actually proved to be useful for me.
In practice, Runt ended up turning into a Sporth-like frontend for patchwerk, with an API that made it much easier to add words from C. To be clear, I had nointention of turning Runt into an initial Sporth. I already had Sporth for that.
Amazingly enough, I'm still using Runt all the time as a low level patching language for monolith, all these years later. It hasn't evolved all that much as a language, because it hasn't needed to. If anything, it's due for a devolution: ripping out all the fancy features I never use and distilling it to be better at what it does now (essentially a DSL for patchwerk).
Lesson learned? Tools evolve over time.
Protrekkr
I really thought I could polish up the codebase to Protrekkr and make it the music tracker of my dreams. But holy crap, this code base is a lost cause. After months and months of persistant refactoring, I finally gave up. This taught me that some things just can't be saved, no matter how good they look (and I still love how protrekkr looks).
Failed Proposals
Okay, I've recently talked so much about this that this is whining now. But this PhD project Proposal got rejected. However, this has proven to be a tremendously helpful exercise to do, and I'm grateful about the process.
More Thoughts On Failures
Messages from my zet linked to the
failure group.
2021-07-09 20:33:29: I may need to look into more of my previous abandoned weeked projects. Lots of failures to reflect and perhaps learn from.
2021-07-09 11:02:01: Creating a new (zet) group for myself #failure. Will be amalgamated in the new (failures) page.