sdf PhD





Exploring visual representation of sound
in computer music software through
programming and composition



Selected content from
a thesis submitted with a portfolio of works to the University of Huddersfield in partial fulfilment of the requirements for the degree of Doctor of Philosophy

December 2013

Samuel David Freeman

Minor amendments
April–June 2014

6.5 Evaluating sdfsys

Existing software did not provide the workflow that I required in order to continue making music with computers, so I made a software system that did and called it sdfsys. The preceding chapters of this thesis document the journey that led from questioning the basis for visual representation of sound in software to the inception of sdfsys, and this chapter has described its development, its present state, and how it has been used in composition.

6.5.1 Ready-at-hand

One of the reasons for creating sdfsys as a gl-ui fronted environment is that the visual appearance of a maxpat is always seen as an invitation to tweak, hack, and otherwise live code the software whilst musicking with it. Practice involving that type of interaction with software continues to be an important part of my art, and it is in that frame of mind that the module unit patches for sdfsys, the meta-patches, and the workings of sdfsys itself are made. By establishing sdfsys as a non-Max-like environment, however, I have introduced a new and different way to interact with the processes that have been implemented as sdfsys module units. Context for this split perspective on creative praxis is found in a 2007 paper by ixi-software authors Thor Magnusson and Enrike Hurtado Mendieta. Martin Heidegger is cited[n6.35] as a philosopher who 'talks about two cognitive or phenomenological modalities in the way we look at the world' (Magnusson and Mendieta, 2007, p. 98):

[n6.35]   Heidegger, Martin. Being and Time. Oxford: Blackwell Publishers, 1995. Pp. 102-122.

There is on the one hand the usage of tools, where the tools are ready-at-hand and are applied in a finely orchestrated way by the trained body, and, on the other hand, the moment when the tool breaks and it becomes present-at-hand, i.e. the user of the tool has to actively think what is wrong with the tool, and look at its mechanism from a new and critical stance. Heidegger takes the example of a carpenter who uses the hammer day in and day out without thinking about it. Only when the head falls off the hammer will the carpenter look at the hammer from a different perspective and see it in its true phenomenological light. As digital instruments/software are normally applied on the computer, we are more likely to have these phenomenological breaks. The tool becomes present-at-hand and we have to actively think about why something is not working or what would be the best way of applying a specific tool for a certain task. In fact, the way we use a computer and digital instruments is a constant oscillation between these two modes of being ready-at-hand and present-at-hand. We forget ourselves in working with the tool for a while, but suddenly we have to open or save a file, retrieve a stored setting, switch between plug-ins or instruments, zoom into some details, open a new window, shake the mouse to find the cursor, plug in the power cable when the battery is low […]

That oscillation between ready-at-hand and present-at-hand cognitive modes has been in mind throughout much of this project, and sdfsys aims to provide a more consistently ready-at-hand experience than I perceive of MaxMSP in general.

In authoring this thesis, I also had that oscillation in mind when writing the term techno-aesthetic for the first time at §1.3; it (techno-aesthetics) has thereafter been found to be a subject of Gilbert Simondon's philosophical writing. To build on the start that has been made in this thesis, my intention is for future research-practice to explore these matters further in relation to computer music.

6.5.2 What's next for sdfsys?

With the publication of this thesis, the software described will also be made public, and I will continue to develop sdfsys; perhaps as _beta2 in the Max 6 environment at first, but the way that windows and fullscreen are managed in Max 6 is an obstacle to my workflow which could speed migration to a completely new implementation of sdfsys. For a long time I have wondered how different the sdfsys environment would become if it were implemented through something other than MaxMSP, and I have speculatively began exploring possible alternatives. I expect eventually to continue version naming in sequence through the Greek alphabet, meaning that the next significant redesign of the implementation would be sdfsys_gamma.


← 6.4 Composing with sdfsys

fixme →