many early morning thoughts!
there totally is (@tyleretters is particularly adept at mapping these things out) and I probably would’ve saved a lot of time if I’d done something like that earlier in the process, but:
- I basically learned Lua as I went, which led to a lot of linear code. each time I wanted the script to do a thing, I added the lines until I’d amassed a Kerouac-style scroll of direct descriptors of what events I wanted to happen + how they should happen this time. this is because…
- cheat codes is an improvisation. this was at times literal (nearly all the v1 features were shaped by improvising with two superb and very patient musicians), but what I mean is that it has a roadmap only in retrospect.
as far as getting the idea out goes, the early process basically oscillated between drawing out what I wanted the grid interface to look like and writing lines of operations for each key. it was super painstaking and made for a ton of work later (more on this in a sec), but that’s because I didn’t know how to code efficiently – and while I was interested in learning how to, I was more interested in getting the idea out of my head and into an interface. this sort of (in retrospect) adhered to the principles of rapid prototyping but like, slower lol. all to say: it helped immensely to assume that getting it done would be better than getting it “right.”
this brute force approach got me to a releasable script. it did not get me to a script that would be easy to modify or extend. the improvisation metaphor continues – the jüj of the process is the feeling of discovery, but when you look back at it the logic is fuzzy. how did things get there? so beyond fixing up broken bits, it was really hard to conceptualize how I could add anything to the script in its sprawling, totally Id state.
that’s where @Galapagoose came in and saved the goddamn day. his direct contribution to the codebase was rewriting the zilchmo. his indirect contributions to the codebase are measured by the fact that there is a cheat codes 2. comparing his version of zilchmo to the previous version is probably the best way to chart the lessons I learned working with him, but maybe it’ll be good to outline some of the core mindset changes he gifted me.
-
before we started, he gave me this assignment:
-
Collect a list of all the global variables (and understand where they are created & what they’re for)
-
Articulate all the data structures in a one location so it’s easier to see how the state of the program works.
-
Divide the program into ‘continuously updating’ parts (ie those with a constant clock), from the parts that respond to events (ie keys & encs, grid, osc?, midi?).
I spent a few hours on this task and it sucked and was so so so super helpful. a small preview:
basically, this exercise revealed how many times I was needlessly repeating the same actions with slightly different variables and how to immediately address how bloated the code had become.
-
this allowed trent to demonstrate Lua’s strength as a functional programming language. you can easily compile the individual actions that make up an “event”, title them, and then call them up whenever you need them. that’s the difference between [this] and [this+this]. the same thing happens, but by wrapping up the events into functions you can spot issues or make changes to the behaviors much more easily. I also feel that there’s something fundamentally aligned between this approach and making music (composition or improvisation) – which makes it super rewarding for writing musical code.
-
as I began to take on the refactor, I just ended up making a ton of hyper-specific little functions that all relied wayyyy too heavily on knowing the state of other variables far outside of their scope. ideally, functions shouldn’t need to know every detail about the other stuff happening in the script – the nouns, adjectives, verbs, etc. instead, they should be more like Mad Libs, where the structure is there to support whatever you throw into it.
I’m still learning how to write code in this way, but it’s how I tried to approach all the new delay functions. for example, there are 4 different ways to change the rate of each delay, which I definitely would’ve spent 60 lines of deeply nested if/then code on in the past (“well, if it’s the left delay do this but what if I’m trying to double it but what if I don’t want to go past 24x but…”) – but by making this stuff a function that accepts clear arguments and routes the changes to the appropriate places, I can really easily change what happens when a “wobble” gesture occurs.
these mindset shifts not only helped me iterate/extend the old code with more agility, it helped me write the core of the new delay system in an afternoon.
anyway. that’s a lot of text, but I hope it helps fill in the picture a bit more – lmk if I can help with anything or answer any other q’s!
