-
Notifications
You must be signed in to change notification settings - Fork 12
The Prototype
The SuperCollider patch this plugin is based on grew out of a longer occupation with granular synthesis and more specifically the lecture of Curtis Roads book "Microsound". It was at first developed without a GUI completely relying on SuperColliders pattern system. In preperation for a workshop on granular synthesis with SuperCollider I gave in 2015 it was developed and given more or less it's current form.
The prototype is split into four files:
INIT_GRNLR.scd, GRNLR_GUI.scd, GRNLR_ENGINE.scd, grnlr_synth.scd.
The files are seperated by task they to keep the code more readable.
INIT_GRNLR.scd contains general setup and initalization of variables and loads and executes the
contents of GRNLR_GUI.scd and grnlr_synth.scd which holds the SynthDef a SuperCollider Class
that is responible for defining the function that produces the sound in the end (that explanation is
of course is criminaly oversimplified).
GRNLR_GUI handles as the name implies all the GUI related operations.
That specifically means setting up the window and handling all the interaction the user has with GUI
elements such as sliders and buttons.
All the variables are stored in a dictionary we initialize at the top of the file. This dictionary is
(in classic SuperCollider style) "sort of global". More precicely it's an environment variable that
is in the namespace of the current environment.
GRNLR_ENGINE.scd contains the main routine (a Tdef or Task definition which is basically a
named routine). This routine is responible for getting the values of all the GUI elements and other
variables and triggering grains with those values.
Later in the handling of MIDI data is defined.
In this paragraph I will try to lay out my initial concept which went into writing the prototype and when necessary point out differences to the finished plugin.
When developing the prototype especially while playing around with it before I implemented the GUI a number of parameters concerning the single grains that seemed useful started to emerge:
- duration (or: inter onset-time between grains could also be described as frequency of grain creation but I felt that would have been to closely associated with pitch)
- length
- volume (or amplitude)
- transposition
- grain-envelope
- timbre
The length of time between the creation of one grain and the next is called duration in my implementation. It interacts with the next parameter "density" to also define the length of a grain making this a "quasisynchronous" granular synthesizer.
The length of the grains is defined as duration * density. In practice density defines the
average number of grains playing no matter if the duration is short or long. This represents a level
of abstraction from the low level parameters of length and duration which aren't necessarily
meaningful in the context of real time use.
The definition of length in that way also simplifies the management of the grains in the
implementation because we know roughly how many grains will be playing at any moment. Because of this
I was able to set the boundaries for the two parameters "duration" and "density" much more freely
than otherwise.
Imagine we trigger grains for 1 second. A new grain is created every 1ms (the smallest possible value in my implementation) and each grain is 2000ms long (much larger values are possible in GRNLR when the duration is also greater). After the 1 second we have 1000 grains playing. My implementation is certainly not efficient enough (or my computer fast enough) to handle that amount of playing grains. When the length is defined as a multiple of the duration however we know even for edge cases that we won't be producing far to many grains. This enables us to set the boundaries for the parameters much more generously. By testing I determined that a density of 80 (the length of of the grain is 80 times the duration) worked fairly well and didn't limit the sonic flexibility of the plugin too much.