There are several examples from past classes that you might find useful and/or instructive for mixing audio.
A useful subpatch for mixing and balancing two sounds
Linear audio crossfade
Using matrix~ for multi-channel audio amplitude control
Using matrix~ for audio routing and mixing
Mixing multiple audio processes
Study the examples from the previous class session.
Keep working toward your research goal. Keep refining and improving your research focus. As you do so, use the MessageBoard to report constantly on your thoughts, progress, revised plans, discoveries, etc.
Come to class prepared to do a short presentation of your progress/findings.
My understanding of the research foci and the plans of action is:
Ryan: Control of 4-color lights via DMX; study of color theory as it relates to color choices for the planned piece; study of previous ideas by composers and others relating pitch (or pitch class) to color/hue; looking into synesthesia phenomena relating color and music; pitch detection of electric bass using sigmund~; ideas for mapping detected pitches to control information for lights.
Hassan: Basics of GL programming in Jitter; applying images or videos as textures for GL objects (videoplanes and other shapes); potential methods of image distortion based on altering the shape of the textured objects; eventually, potential mapping strategies for relating music and video.
Lizzy: Research and learn the workings of certain basic delay-based audio signal processing techniques such as echos, filters, comb filtering, flanging, chorusing, etc.; record piano samples to use for testing effects; test effects with the sampled sounds, try different parameter settings, and make a library of interesting and musically useful results; consider ways that the Disklavier can contribute to this process.
Richard: Research the basics of the mathematics of probability as it applies to probabilistic decision making; research applications of that to algorithmic composition that may have been explored by others, and that you experiment with yourself; research ideas of interest in the area of machine musicianship, and see if there are connections between that and probability; consider what interface(s) might be best for multi-dimensional (orthogonal) control of parameters in a performative way.
This patch demonstrates how to adjust the delay time of a comb filter to make the filter correspond to a desired fundamental pitch.
The filtering formula used by the comb~ object is
y[n] = a x[n] + b x[n-(DR/1000)] + c y[n-(DR/1000)]
wherein R is the sampling rate, D is a delay time in milliseconds, x[n] is the current input sample, y[n] is the current output sample, and a, b, and c are gain scaling factors.
That formula can be shown diagrammatically like this.
In the patch we convert a MIDI-based pitch number into a frequency in Hertz, then use that to calculate the correct delay time for the filter. Using delay feedback (a past y[n] value) with feedback gain approaching 1 creates strong resonance at the comb frequency, yielding an inverted comb response pattern sort of like this,
resulting in a strong imposition of the fundamental pitch and a buzzy timbre.
One potential use of the “inlist” abstraction is to compare incoming pitches to a pitch class set. This patch uses a % 12 object to find the pitch class of an incoming pitch, then compares it with the members of a prescribed pitch class set. If it belongs to the pitch class set, it gets passed on unchanged; if it doesn’t belong to the pitch class set, it gets pushed up one semitone and tested again.
Note that this patch does point to a potential bug (a so-called “screw case”). If the pitch class set is null (the bag inside the inlist abstraction is empty), any incoming pitch would set this patch into an infinite loop and cause a stack overflow. However, we’re safe in this particular example because we have pre-loaded the pitch class set and there’s no way provided in the program to delete those numbers.
This abstraction, which I call “inlist”, checks to see if a given number belongs to a previously-collected set of numbers. Numbers in the middle inlet are added to the set, and numbers in right inlet are deleted from the set. A ‘clear’ message in the left inlet deletes the entire set. When a number comes in the left inlet, if it belongs to the set, a 1 will be sent out the outlet, meaning “yes, it’s in the list”; if it doesn’t belong to the set, a 0 will be sent out.
The bag object stores an unordered collection of numbers. Each time a number comes in the left inlet, we store it, then compare it with every number in the bag, storing any “yes” answer we may get. Then we send out the stored answer and reset the stored answer to “no”. (N.B. Technically, we really reset the stored answer before we send out the result, so that “inlist” will be all ready to go even if its output triggers more input in the parent patch. The answer actually gets to the final t object and is stored there for an instant while we reset the i object to 0.)
