Patch History
I've always found the concept of machines and software capable of autonomously playing
music intriguing. Whether looking back at the old Greek mechanical devices like the
'Laternas' or exploring post-modern systems like Xenakis UPIC, I've harbored a desire to
create something similar. As a musician, relinquishing control to a machine during a live
performance can be liberating, ranging from minimal to complete surrender. Simultaneously,
there's a profound challenge in encapsulating the core of one’s musical essence into an
algorithm. John Cage's pursuit of eliminating personal ego from the final music result
resonates with me. Does this ego removal truly occur, considering it's acknowledged in the
method but seemingly absent in the performance?
As an electronic music performer, I've dedicated years to refining my methods, continually
rediscovering myself for each new performance by retaining what works and discarding what
doesn't. However, over the last six months, my synthesizers have collected dust on the
shelves, leaving my desk adorned with just three items: my laptop and two speakers. For the
second time in my life (the first being 20 years ago), I've delved back into the realm of Pure
Data.
The motive, a public sound installation for the municipality of Chania in Crete. The
installation featured eight speakers strategically placed in an outdoor area, playing randomly
selected manipulated recordings. Regrettably, the project's budget constraints prevented the
acquisition of all the required equipment for a seamless implementation, particularly in terms
of wireless sound transmission from the computer. Nevertheless, a substantial portion of the
groundwork was laid through the development of a relatively straightforward Pure Data
patch. Despite the challenges, the project was successfully completed, reigniting my
enthusiasm for working with Pure Data.
Enter Esotropio
In essence, the patch serves as an automated sample sequencer with dynamic capabilities.
The user has the flexibility to designate eight distinct sound banks from a computer folder.
The patch, in turn, autonomously plays these samples in a semi-randomized sequence and
time frame. As the patch progresses, it adapts its sequence by analyzing the frequency of
each played sample. This data is stored in temporary memory, allowing users to selectively
recall specific samples or collections based on identified frequencies. Moreover, users can
analyze the frequency of a monophonic line or microphone input, enabling the automated
recall of samples in a live sound environment—a valuable feature for on-the-fly sample
accompaniment.
The patch's sonic aesthetics reside within the experimental micro-glitch soundscape genre. It
transforms any input into a fluid entity where familiarity morphs into the avant-garde. While
the patch inherently produces a distinctive timbre layer, careful selection of imported
samples can further shape the overall output. Although intriguing results can emerge from a
random sound selection, intentional curation of specific pitches and dynamics elevates the
patch's potential. Designed for immediate playability, the patch simplifies user interaction by
loading samples and initiating play with minimal parameter adjustment. However, users
retain the option to customize the patch's behavior according to their preferences, providing
a versatile balance between accessibility and personalization. The latter includes
intervention by the user to the time triggering relations and spectral characteristics of the
samples.
Main Signal Patch
The patch comprises six intricately linked stages along with various peripheral features,
where nearly every element interacts with one another. This interconnectivity is crucial in
shaping the holistic behavior of the final output. To illustrate, the frequency of each sample
acts as a trigger for an internal phase modulation synthesizer, and the time-based playback
of a sample initiates the start or cue point of the sampler. Additionally, the volume of a
sample engine holds the potential to influence delay feedback, while the frequency of a
microphone input can serve as a trigger for the introduction of new samples with similar
frequencies. This intricate network of interactions forms the foundation for the dynamic music
expression of the patch.
Stage A
The patch is based on eight sample players triggered by counters and triggers, a variation of
Martin’s Brinkmann patch Cells. Initially the main tempo trigger is set by either three different
sources.
1. A Low Frequency Oscillator producing 1/f noise behavior.
2. OSC protocol (Tested with Sensor2OSC mobile app and phone gyroscope ).
3. Manually by the user.
There are eight different interconnected counters with a threshold. The tempo source initiates
the procedure and when each counter reaches a certain threshold value (by adding the
number of excitations), it fires a bang to trigger a randomly (or requested) selected sample.
The user is able to define the number of excitations before each player fires a sample.
Therefore, the final output of a sample by an engine player is a combination of three different
points: The main tempo (main trigger tempo as defined above), the number of excitations
from the counter, and the excitations it receives by the interconnection with all other
counters.
Hint:
For a long scattered soundscapes use a large number of counter values along with
user defined tempo.
(Note: samples can also be triggered by other means, like asking for a certain frequency by
the user or by triggering samples from the frequency of the mic input). The volume of each
sample player is set by a Low Frequency Oscillator producing a 1/f noise behavior.
In the first source option the Low Frequency Oscillator outputs random values with
interpolation which are scaled from 200ms to 20 seconds. One of the excitation triggers
mentioned above forces the oscillator to produce new random values. In the second source
option the time triggering is defined remotely (wirelessly or not) based on a communication
via the Open Sound Control protocol. The final option is defined precisely by the user.
Stage B
All eight sample engines are then fed into a stereo reverb (Free Reverb). The option to insert
a reverb so early in the signal chain can look strange but it is an aesthetic decision which
works nicely with the rest of the patch. The reverb settings are not accessible by the users.
The patch now splits in stereo and passes through two crossfaders, one for each channel,
where they crossfade the left and right output, giving a sense of a moving space. At this
point the external input is also introduced to the patch.
Stage C
Each channel left and right is fed into two loopers. The Start, Cue and Stop points of the
loopers work either manually set the user in real-time or randomly (initial state) triggered by
the Stage A triggers. The user has the option to activate / deactivate the loopers and to
intervene at any time, setting new loop points or deleting existing ones.
Stage D
Each channel left and right is fed again into a dedicated pitch-shifting reverb - one for each
channel (Pierre Massat Patch). All parameters of these reverbs are completely automated
using again the same 1/f noise oscillator algorithm. The Phase Modulation synthesizer is
also introduced here (see below).
Stage E
The two channels L / R are split into four signals (Pitch-Shifted signal L & R - Dry Signal L &
R) and fed into four different inputs. A couple goes directly to the final output, while the rest
pass through a simple feedback delay with automated feedback and a sampler with a
time-stressing function. The sampler records continuously into an array and outputs a
time-stressed signal with a random value. The sampler can be activated or deactivated by
the user. An extra output passes through the [secret recipe] effects.
Stage F
The remaining signals coming from the delays, the sampler and the [secret recipe] are
finally mixed and arrive into the final stereo output.
Additional Features
Phase Modulation Synthesizer
The patch boasts an additional feature, introducing an optional Phase Modulation
synthesizer into the signal path. While a detailed explanation of this synthesizer exceeds the
scope of this manual, it is fundamentally derived from a patch found on the Patchstorage
forum, extensively modified to align with the objectives of this project. In essence, the
synthesizer involves modulating an oscillator with a sample & hold object, both of which have
their frequencies controlled by the frequencies of the playback samples. Integration of the
synthesizer into the patch can occur manually or automatically. In both cases, the
synthesizer is triggered only when the frequency of a sample falls within a specified
frequency bandwidth. The difference between [user] and [auto] mode is only for the
initialization of the synthesizer. In either of these modes if there is no frequency detected
within the specified boundaries no sound will be produced. Notably, the synthesizer includes
an automatic (or user-defined) Freeze-Unfreeze function, activated by both Stage A triggers
and counters. Freeze behaves as you might expect, freezes the sound at a specific
frequency.
Playback From a Given Frequency
In addition to the main automated sample selection, two more distinct methods facilitate
sample playback. Each played sample undergoes frequency analysis, with the resulting
frequency value stored in an array. Users can input preferred frequencies (up to 8),
prompting the patch to recall samples associated with these specific frequencies. These
samples can be played manually or automatically. Furthermore, frequency-based sample
recall can be initiated through a microphone or a line input connected to the patch.
Input-derived frequency values, whether manually or automatically generated, guide the
retrieval of similar frequency samples. Both input and output frequencies for all search
requests are calibrated based on MIDI values (90-127). Recalled samples can be played
concurrently with the primary sample generation of the patch or in isolation. It is essential to
note that this feature, while versatile, may not achieve 100% accuracy and is optimized for
monophonic sounds only. This imperfection however can lead to some interesting happy
accidents, it should not be seen as a scientific method of finding the frequency of a sample,
but as an extra tool for algorithmic music exploration.
Microphone Input
Pressing the [ini mic] activates the microphone input. The user can mix the microphones
input with the sample playback and also get the frequency of an external signal. A search
can be done then automatically or by a user request for similar frequency samples.
Secret Recipe
The [secret recipe] fx processor directs the signal within several fx points. First the signal
passes through a Spectral Crossfader [morph~] which allows you to make a spectral
crossfade between the amplitudes and phases of two inputs. It then goes to a Frequency
Shifter [freq.shift~] where the frequency of the sound is shifted from a random value. It has
two outputs, one with the shifted signal and the other with the signal shifted in the opposite
direction. Finally it passed through a feedforward line Echo device, with a set number of
echos. Using the [secret recipe] selector a user can manually change the routine of the
signal and drive it through these effects. The state of this selector is also triggered randomly
by stage the A counters.
Following initialization, the patch autonomously generates music, offering a unique
and non-repetitive auditory experience. While users have the flexibility to experiment
with settings in real-time, the patch is designed to operate seamlessly in an
unattended mode, delivering hours or even days of continuous, ever-evolving musical
compositions.
Technical Challenges
The development of the patch presented two primary challenges. The first pertained to
intelligently triggering the samples, while the second involved devising an effective solution
for accurately representing the frequency of each sample and establishing a robust
connection with the corresponding file number.
Ensuring a judicious triggering of samples was crucial to achieving a balanced playback.
Striking the right balance was essential, as an excess of triggers left no room for pauses—a
crucial element in realizing my original vision. Conversely, overly sparse triggering risked
leaving the listener unengaged. In the initial version of the patch, I had not considered the
option of allowing users to weigh the playback, focusing instead on the complete
self-generation of the patch. Consequently, I sought a middle-ground solution, which
materialized in the form of a low-frequency noise oscillator emulating a 1/f noise function.
Tactically adjusting the oscillator's frequency yielded the desired temporal effects. Similar
oscillators found utility in other sections of the patch, governing parameters like volume
sliders for sample playback.
As the patch evolved, the need arose for an additional layer of time-triggering to enhance
control. As detailed in Stage A, triggers and counters introduced this extra temporal
dimension. Striking a balance between these two time generators provided heightened
control over the temporal aspect of the patch. This feature also introduced the capability to
individually weight the triggering of each of the eight sample engines. Consequently, by
organizing samples within the banks based on pitch, amplitude, time, or spectral
characteristics, users gained more control over the playback of each sample bank, offering a
nuanced and tailored user experience.
Determining the frequency of a wave file that extends beyond a few seconds presents a
realistic challenge. Sound, inherently dynamic in both the time and frequency domains,
makes tagging environmental sound samples—central to my original concept—with a single
frequency value unattainable. Despite concerted efforts to navigate this hurdle, achieving an
ideal solution proved elusive. Nevertheless, I explored a couple of viable options, subjecting
them to rigorous testing. One approach involved capturing a snapshot of a sample at regular
intervals in real-time, temporarily storing these snapshots in a table array, and subsequently
calculating the mean frequency value. The alternative method centered around leveraging
either the frequency at the onset (attack) of the sound or the frequency at the conclusion
(release) of the sound. Following extensive hours of testing and attentive listening, I opted for
the latter solution—capturing the closing frequency of the samples. This choice, grounded in
practical considerations and thorough evaluation, provided the most effective means of
addressing the inherent complexities of capturing the dynamic frequency characteristics of
longer sound files.
Final Notes and Future Implementations
The patch currently accommodates .wav and .aiff files with a resolution of up to 24 bits /
48kHz. While it is in beta and may contain potential bugs, I welcome any reports or feedback
you may have. Please feel free to share your findings at the address provided below.
Although I have a list of additional functions I aspire to integrate in future versions, the extent
of my commitment largely depends on the feedback received from users like you. Your
insights will play a crucial role in shaping the direction of future updates.
The following functions and reconsiderations would probably be addressed in the future:
1. A spectral modulation between the sounds aiming to produce completely new
timbres.
2. A better version of the looper where Cue points will search for zero-crossing points.
3. A search for samples by their harmonic context and amplitude.
4. Up to eight channel output.
5. A more sophisticated algorithm for Freeze and Unfreeze functions.
6. A test of different synthesizer engines.
7. A wiser frequency calculation of the samples.
8. A graphical interface where the user will be able to draw instead of write certain
values.
9. MIDI Out connected to the sample frequencies.
10. Ported to another platform as a completely standalone or plugin application.
////====
==== ////
If you like to use Esotropio: mailto: tokenomusic@gmail.com for info.