As musicians, we grapple daily with the task of situating ourselves in a field of nuance, subjectivity and opinion, and the journey toward musical expression couldn't be further from a linear trajectory on a 2D plane. It is at once bewildering and liberating to realise that the knitting of one aspect of your craft may require the unravelling of another. So there is something wonderfully freeing in becoming acquainted with the primary building blocks of computer systems, languages and logic - booleans.
In the first Scordatura post, "I can't, I have rehearsal", I posited that code either works or it doesn't, and that as a musician, I find that incredibly freeing. Given that I currently have the coding vocabulary and fluency of a milk-drunk infant on the one hand, and what that naïve statement reveals about my "it's complicated" relationship to music on the other, I think it is probably something that warrants exploration.
It's an oft-repeated mantra in the #CodeNewbie world that one shouldn't despair of one's broken code. Broken code is the very material of a coder's work - if it's not broken, you're not needed.
While there are certainly parallels in music - private practice and technical improvement, aspects of the rehearsal process - the idea of reaching a terminal point at which the music is correct, and therefore no longer needs you, is anathema. The better it (or our execution of it) is, the MORE we are called upon to do it. Even "definitive" recordings and urtext editions are inevitably followed by successors, for financial if not philosophical gain.
I suppose there is an equivalent in code; thank goodness we didn't park our computer-based design aspirations at ClarisWorks 1.X, for instance. Software is constantly being updated, upgraded, swallowed by other software and, sometimes, retired. (Though, I'd love to see how much DNA from those very early software programs is still present in the bones of current code bases).
But is it as simple as Code is a case to be closed, and Music is a conundrum to be... chewed, worn, endlessly retraced or revisited?
Code, at its smallest quotient, is built upon binary. Billions of 1s and 0s, each equivalent to either true or false. The hardware circuitry in a computer is built the same way. From the largest of actions (pressing a key or not pressing a key) to the most primal layer of computation (is the computer receiving an electrical current or not), everything passes through, and is evaluated by, a boolean logic gate (true or false), translated through binary (1 or 0).
This also extends to the grammar of coding languages. The muscle and sinew of code blocks is binary logic: If this, then do this. If not, don't.
As a conductor, this isn't entirely unfamiliar. I make any number of directorial decisions about the score in advance of rehearsal, and (consciously or unconsciously) posit the most efficient or effective gesture to convey this to the musicians. Then, in the rehearsal or recording session, I make my gambit: this gesture should produce the sound I want. If it doesn't, a sort of analogue computation takes place - how did it diverge from the sound I was aiming for? Was it my fault (undoubtedly)? What can I do to adjust it? A series of instantaneous decision-making processes based on logic.
The difference, of course, is that the logic I use is mainly developed by experimentation, experience and observation, rather than mathematics, and acts in tandem with unmeasurable factors like instinct and the occasional optimistic or desperate punt. Furthermore, the "computer" I program as a conductor is made up of humans and human-made instruments, and human-designed and -built acoustic spaces, and as such there is so much I cannot factor into an equation. The same piece with the same orchestra touring to different concert halls will be played differently every night, depending on things as profound and arbitrary as humidity, acoustics, the audience's energy, orchestral politics and hangovers.
And thank goodness for that. It can be challenging to convey to student conductors and even some orchestral musicians, that the pursuit of perfection, or correctness, may not be the path we're supposed to follow. At least, I would argue it very rarely leads to the most interesting or beautiful performance. (How unfortunate, then, that so much of the education and marketing structures in art music place perfection on such a lofty pedestal).
But more fundamentally, in that moment of decision-making as a conductor, the possible pathways to take are, literally (though perhaps not practically) infinite. And while there will be idiomatic, stylistic or pragmatic factors that favour one path over another, arranging them into some wobbly sort of ordered list, at the end of the day none of them is measurably "true" or "false". Once the decision is made - the path chosen, rather than evaluated by a binary logic gate - the auditory outcome of that decision, and the effect it has on the sounds still to come, remains the responsibility, property and measure of the performers.
That ownership weighs heavily, at times, and every ear in the room will judge the outcome differently. But perhaps, in that weight, is the unique value and possibility of art - mercurial, infinite and ephemeral, yet indelibly tied to its many makers.
Binary logic is not just the domain of mathematicians and coders. It's a fascinating topic to explore, and is far more accessible than you might think.
If you enjoy a hefty read, check out Charles Petzold's tremendous book Code: The hidden language of computer hardware.
To delve into the mathematics of logic, this 1-hour long freeCodeCamp crash course is brilliantly taught:
And if you want an even lighter intro, legendary coding teacher Commander Candy has a really fun, and easy to follow, lesson on it here:
Enjoyed the blog? Subscribe to our newsletter to receive it delivered straight to your inbox
