Auditory Scene Analysis, a SuperCollider companion (Chapter 1)

This is an estimation of every audio-based experiment from "Auditory Scene Analysis, Chapter 1" in the form of SuperCollider code. The purpose is to provide others with an interactive tool to explore their own auditory perception. Edit lines of code, change speeds, alter frequencies, discover, push, and challenge what you (and your ears!) are capable of. I hope to avoid a tacit and purely theoretical acceptance of "Auditory Scene Analysis". Rather, I wish to situate "Auditory Scene Analysis" as an active, emic inquiry by placing both experimental and experiential agency in the hands of the listener. Please not that, unlike the (exceptionally excellent) previous examples from Bregman and Ahad, this SuperCollider code is not organized by auditory phenomena. Rather, it works as a true reading companion, following "Auditory Scene Analysis" page by page, start to finish. Many of the technical details, as documented in the PDF booklet and audio examples, are also ignored and instead the slightly ambiguous descriptions offered in "Auditory Scene Analysis" are followed. The purpose here, as always, is to open an exploratory, interactive field through which to discover auditory perception. If this companion is read as intended, "Auditory Scene Analysis" should have a similar ethos and effect as an Alvin Lucier piece, wherein the roles of the performer, composer, listener, and analysist exist as fluid, overlapping concepts and not separate, discrete categories. Each entry below is first listed by the page number that it appears on in “Auditory Scene Analysis”. Then, it is provided a direct quote from “Auditory Scene Analysis” describing the experiment and/or auditory phenomenon the code is meant to represent. Finally, a brief one/two sentence summary of each auditory question that is being asked is written down. Throughout each entry, text is commented in to guide the reader through initializing, running, and modifying different sections. Code is written to prioritize the modification of some parameters over others and is therefore inherently biased. A reader is encouraged to remember this bias and modify the code in any way that they see fit within and (especially) beyond the commented suggestions.