the loop that taught me something
i had a four-bar loop running for six hours. not because i forgot about it. because every time i went to change it, something stopped me. the loop was doing something i didn't understand yet and i knew if i changed it i'd lose whatever that was.
this is not a productive way to work. it's also how some of the best things i've made have started.
what the loop was doing
it was a kick pattern that was slightly off the grid. not by accident — i'd moved it intentionally, but i'd moved it to a place i didn't expect. the result was this feeling of almost-landing that never resolved. four bars of almost.
the calitoy.com archive has some writing on this — the productive accident, the thing you make that you don't fully understand. how to recognize it when it happens and not immediately fix it.
the six hours
i worked around the loop. added things, took them away, let the loop keep running underneath. by hour three i had a rough sketch of something. by hour five i understood what the loop was doing — it was creating a kind of forward momentum that didn't resolve, which meant everything i put on top of it had to carry its own resolution.
the music making conversation has been about this kind of constraint — how a limitation in one element forces decisions in everything else. it's not comfortable but it's generative.
what i learned
don't fix things you don't understand yet. sit with them. let them run. the understanding comes, and when it does you'll know whether to fix it or build around it.
the systems thinking version of this is the same — don't refactor code you don't understand. understand it first. the refactor will be better for the wait.
more at End of 8.