6.1 Introducing sdfsys
Before describing, in turn, each of the two sdfsys builds, the following introduction provides orientation of the general principles that are common to both the _alpha and _beta versions.
6.1.1 Overview
In sdfsys, audio data is stored in two-dimensional data-matrices that can be visually rendered to screen in a very direct way: each data-matrix has one-plane of float32 data-type, and a number of view modes are implemented for the mapping of that data to the four-plane ARGB colour-space of the computer screen. In the main area of the jit.gl based user interface (gl-ui) the data-matrices are visually layered, each one atop of another. The modularity of sdfsys is based on a unit-generator paradigm in which data is written to, and read from, those matrices by specifically structured patches that are loaded into the sdfsys environment. The emphasis of the system is upon controlling those data-processes in terms of their visual manifestation within the display, and soundmaking occurs through the interplay of multiple processes acting upon different matrices.
Text is used both by the human (to instruct the system) and by the system (to inform the human), and a basic text editor for qwerty-based interaction has been implemented for sdfsys. This part of the system is also based on a data-matrix, but in this case it is the char data-type that is used. The ASCII-numbered glyphs represented by the cell values of the 'text-buffer' matrix are displayed as a layer of text over the audio-as-visual-data layers in the main area of gl-ui. The syntax implemented for text input to sdfsys includes several types of command: there are commands, inherited from thisis (introduced at §5.1), for specifying and drawing with points on a plane (drawing to a data-matrix); there are commands by which to load and control unit modules within the system; and there are commands by which to directly address aspects of the sdfsys environment and its host (MaxMSP).
Parameters of the loaded modules are represented visually as mouse-movable sprites. These sprites are layered, in the main area of the gl-ui, over the data-matrix and text-buffer displays. Various mappings of position-on-the-plane to parameter-value coexist on the same area of the screen. Each type of parameter sprite has a different mapping, such as Hz (spiroid), point (cartesian), radial (linear distance from a reference sprite), and others.
6.1.2 Construction aesthetics
Certain aspects of the system have been implemented with intentionally low resolution, as motivated by various aesthetic and pragmatic objectives. The data-matrix dimensions, for example, are set at 400 by 400 cells; the font used for the text editor is of a large size which not only allows the text to be read from some distance, but which also promotes focus on just a few command lines at a time. Awareness of, and concentration on now are encouraged when musicking with sdfsys.
The architecture of the system has evolved gradually over time. Although some factors were thoroughly planned before being programmed – and others (such as thisis) were imported, almost directly, from my previous works – some parts of the system emerged only through modifications being made, ad hoc, along the way.
The sdfsys environment emphasises certain aspects of the software medium in the creative process, and subdues (or even subverts) other aspects of contemporary praxis. Although the sdfsys environment has been implemented within the MaxMSP environment, when one is working in sdfsys one need not see any maxpat interface beyond the (small) top level patch, which includes a clickable shortcut to fullscreen viewing of the gl-ui.
6.1.3 Eight spaces
The modular aspect of sdfsys is implemented through conceptual 'spaces', of which there are eight, and into which can be loaded the available unit modules. A unit module is an appropriately structured abstraction maxpat. For each of the eight spaces there is a Jitter matrix that exists within the sdfsys environment independently of the structured modules that may act upon them. All module abstractions are expected to write data to the data-matrix belonging to the space they are loaded into, and modules may optionally read data from the matrix of another space. Interconnections between the eight spaces thus form 'the spaces network'.
6.1.4 Making sound
The primary soundmaking method of the sdfsys environment is based upon the control of shape and pattern in the visual domain while listening to the sonic results of the thus controlled processes. Sound is made in sdfsys through exploration of the audiovisual synthesis methods made possible by the spaces network. The method is based mostly on the principles identified through the creation of my conceptual model of a gramophone (§3.4); the creative potential of this soundmaking technique is expanded by modularising the read- and write-head aspects of that model.