Chapter 4: Programmability & Sound Design

Principle 4.2: (Interesting) Sound is motion (over time). hits me by on multiple aspects of sound. At its core, sound is generated by the vibration of an object, which in turn sets air molecules into motion, then propagating a mechanical wave through the medium. The phyiscal foundation of sound only exists with motion. In the context of music, repetitions are boring. When hearing pitch created from a fixed-freqeucny vibration, we feel urged to layer sinusoids to construct timbre. Then a single note becomes boring, whic leads to scales and intervals. After that when a repeated interval seems too simple, sequences of pitches, aka melody is created. I have to mention that we sometimes also find repetitions useful, in contrast to a forever-in-motion sound. When we sometimes get lost in the development section of a piece, the sense of structure and 'theme' is confirmed when the main material reappears. The patter of music creation above also follows Principle 4.3: Build complexity as the sum of simple elements. Another example is creating a pitched sound from a train recording via comb filters. From the time domain perspective, a comb filter simply feeds back the samples to constructivly or destructively interfere with the original signal until the resonance builds up. Extending these considerations into the tools perspective, I want to respond to Principle 4.10: Programmability is both blessing and curse. From my experience as a Chuck user, the down-to-sample level of control empowers my exploration of 'chaotic' synthesis. But when I started to take things for granted, bug creeps in from the creases of my code. For any programming tool, errors can be introduced at multiple levels, ranging from algorithmic inaccuracies to software bugs (segmentation errors). Additionally, the flexibility inherent to programmability often demands a deeper understanding of both the problem domain and the computational tools at hand, raising the bar for entry and potentially leading to the misuse or misinterpretation of technology. In the end, I would prefer a highly programmable tool, so that the means are given back to the users instead of being kept by the developers. Nando's talk last week (10/18) on free & open source software has been inspiring on this matter.