delRM_01 is a piece written for keyed and bowed guitar, and initially for prepared electronics, although the version that I ultimately performed for our final presentation did not include the prepared electronics. The piece developed out of the idea of exploring progressively increasing delays, feedbacks and modulation on a selection of source musical material, as well as a focus on experimental instrumental technique, in this case, for the guitar. Some of the works that I had listened to and that had inspired the initial idea of the composition included Franck Bedrossian’s Tracés D’Ombres (2007), Rob Ashley’s The Wolfman (1964) and Swan’s Screenshot (2014). My idea was to use repeating musical structures within live processing of progressively increasing intensity. What emerged out of my attempts to program an audio processing system for this piece was an expansive tool, which I will attempt to experiment with in a future series of compositions in a similar vein to delRM_01, perhaps expanding its functionality along the way. The following text will outline the essentials of how the patch for both versions (the one performed in my presentation, and the intended original version) of the piece functions.

INPUT AND ROUTING

The patch has two audio input options, an adc~ input for a live performed instrument in a performance/recording context and a playlist input for playing back sound files in testing and troubleshooting. These inputs are both routed to the central matrix~ that serves as the main routing object for audio in the patch. It routes the input signal to the effects modules and the effects modules’ returns to the four outputs.
In the future, I hope to expand the patch to include playback for a four-channel system but in this iteration, the four outputs are scaled down to a stereo output. From the matrix~, the input audio is sent as a clean signal to a fifth output, and then to the delay module and then either directly out to an output, or to a ring-modulator and then an output. The matrix routing is automated in a patcher section in which, when banged, the four channels are randomly re-routed. This section uses an urn object so that the channels are sequentially routed and so that repeat or double channel routing is avoided. The probability of routing the delay directly to the output or through the ring-modulator first, is preset by a message to this patch section. Over the course of the piece this probability changes so that more of the ring-modulators are active in the later sections of the piece. The matrix routing section also contains the encapsulation p matrixroutinganalysis, which ensures that whenever the matrix re-routes the audio, one ring-modulator is active. The matrix is re-routed whenever the piece moves into a new section.

AUDIO PROCESSING

The audio processing in the piece consists of two stages, a delay stage and ring-modulation stage. The delay module creates four different delays on the input signal.

The delay time is randomly generated on bang within a parameter constraint i.e. low, mid, or high delay. These are produced by a random number between 0-127 to facilitate the slider object and then scaled to between 100 and 16000 milliseconds. The probability of low, mid, or high delay, as well as the feedback value, are predetermined by the section parameters of that section of the piece. Each delay has its own preset feedback for each section and a unique delay value is generated in each of the four delays as well. The general progression in the piece is that of more low delays in the beginning, transitioning to fewer low delays and more high delays in the end.

In the current version, the pedal that I used changed the way the delay section functioned. The pedal served as a kind of ON/OFF switch for the delay unit. In the ON state, the delay unit functions as described above, but in the OFF state, the feedbacks are ramped down to a value of 0.1. This stops long, echo-like delay effects and is used when a quicker decay of sound is required.

In the ring-modulators, the modulation frequency is the only value being altered. The first RM contains a probability patcher that determines whether the ring-modulation will be 1) short, and gated, 2) long and bassy, or 3) long and higher pitched. This value is then sent to the other three RMs, to the sub-patcher p ringmod-n-effector. This patcher either multiplies small modulating frequencies or divides larger ones by a randomly selected integer, so that the modulation frequencies of the three remaining RMs are multiples of the modulating frequency of the main RM. I did this to make the RM effect more cohesive across the board.

AMPLITUDE TRACKING AND VALUE CHANGES

The amplitude tracker uses analyzer~ with a trigger threshold to essentially detect when the performer plays (by detecting when the signal is above a certain amplitude – the trigger amplitude).

When triggered, the amplitude tracker will not report further "attacks" until it detects that the signal level has fallen to the noise floor (i.e. there is no more signal coming in, or the performer has stopped playing). After reaching the noise floor, a gate is reopened that allows an increase above the trigger amplitude to once again trigger certain changes in the rest of the patch. It generates new delay times in each of the delays, as well as a new modulating frequency in the master RM.

This trigger also sends a pan sweep through each of the four processed audio channels. The four channels alter between four preset pan values that can be adjusted as desired.

The delays are changed instantly, but the modulating frequencies are ramped over a period between 1000 and 14000 milliseconds. The patch has a safety mechanism that ensures that until the modulating frequency ramps are completed, no further "attack" detections will trigger changes in the patch (a gate between the trigger for the parameter changes and the actual processing modules is shut until the ring modulation ramp is completed).

OTHER INFORMATION

Generally, all the parameters that are changing have sends and receives in and out that allow for remote communication across "long distances" and between sub-patch and b-patcher levels. In the original version, the pedal is used in two ways; as a trigger for prepared electronic files, and as a kind of score tracker, based on the number of presses counted by a system of counter objects.

In the original version, where playback of sound files was included, the patch would use these counters to play audio in one of three sfplay~’s. The sound files were stored and recalled via a coll and the index listing of the coll corresponded to the pedal press count detected in the patch. Essentially, certain sound files were cued to certain pedal presses.

However, in this iteration of the patch, the pedal does not trigger prepared electronics (which were left out of the performance). Instead, the pedal acts as a switch for engaging and disengaging the delays. An initial press of the pedal is used to calibrate the patch on startup.

OSC CONTROL

A final feature of the patch is the use of TouchOSC with udpsend and udpreceive objects to control certain parts of the patch (toggles, gains). In the version performed in class, the OSC had the additional feature of changing the piece sections, since the pedal was used for toggling the Delay function in this iteration. The OSC interface I used is a custom interface created in TouchOSC editor.

The last two features I would like to talk about are related to the original iteration of the patch. Since that version featured playback of audio files, those files needed to be loaded into the coll object when the patch is transferred to a new machine. To that end I developed a way to load these files easily using a dropfile mechanism.

The last feature is a reset mechanism, which allows the performer or a technician to reset the patch to the start of a particular section, in case something goes wrong during the performance, or simply to reset the patch. The section uses a umenu that, depending on its index output, resets the patch parameters to those corresponding to the selected section.