Roses don't need perfume for guitar and electronics, PD patch

This is the live performance patch for my solo guitar and electronics piece, Roses Don't Need Perfume. It's a simple example of a user interface and had to be fool-proof so that the guitarist, Ken Meyer, could run it on his own system, edit it as needed for a particular performance. The patch utilizes my sfplayer abstraction, a reusable soundfile player object with a nice user interface. The patch is documented internally and may be used and modified under the GPL (GNU Public License).

Tutorial 1 - A simple event counter

A great composer does not borrow, he steals

On of the motivations of open source software is to share software solutions, hoping to save the time and energy of "reinventing the wheel" but providing a base for others to extend and make better, more capable, or part of something larger.  For this reason, I recommend whole-sale "stealing" of working open source code from me or wherever you can find it. In this case, the PD Help system provides several solutions to the initial problem of builiding an event counter, that of the couter machanism itself. Here's one stolen from "2.control.examples.pd -> 06.more.counters.pd":

Perfect. Our event counter will do the same, count to 10 and then reset...assuming our piece has 10 events.

The center of the action is the [float] object, a simple place holder for a number (all numbers in PD are floats). [metro] is a metronome that sends a bang every time increment, in this case every 500ms (0.5 sec). The bangs from metro tell [float] to pass along the number it's holding, initally "0". On the first bang, that "0" goes on to the [+ 1], adding 0+1, and the new value is returned to [float] at it's left, "cold" inlet. The new value, "1", is thus waiting in [float] to be passes along at the next bang to the left or "hot" outlet. 500ms later, [metro] bangs [float] once again. [float] passes the "1", which is again passed to [+1] and back into [float] as "2" (1+1), and so on. The only thing stopping [float] from counting forever is [select]. When [select] sees "10", it sends a bang out of its left-most outlet, banging a [stop ( message for [metro] and stopping the counter.

Counting in response to a click

We'll make several small changes to this mechanism, removing the metronome so that the counter only advances when the mouse it clicked, and using [select 10] to reset the [float] value to "0". Of course there is also an object in PD, taken from Max/MSP, called "counter" which integrates this behaviour. 

Lately, I have taken to building mouse foot pedals for performers out of old one-button Mac mice, a process I will document here in the future. The key object is from the GEM library, called "MouseState" which checks whether the mouse is clicked, where it is on the screen, etc. In our case I just want the click state, up or down (0 or 1). In the patch below I use "select" to set the "polarity" of the mouse foot swtich so that it clicks when the foot is released/up. When select gets a "0" (mouse click up) it bangs our counter. Many players prefer this but it is easily reversed ([select 1 0] for those who don't.

Tutorial 2 - Send and receive with graphical objects

Send and Receive

The send and receive mechanism in PD provides a wireless message communication system, a way of sending data from place to place, patch to subpatch, etc, without making cable connections. There are several ways to do this: with send/receive objects, with message boxes and semicolon separated values, from one graphical object to another within its properties, and from a qlist (an advanced topic we will get to in a future tutorial). Please see PD's Help system, "2.control.examples/send_and_receive.pd" for examples of the first two.

The third, sending and receiveing to/from graphical objects, is very handy but somewhat problematic. One of the stated goals of PD is to have printable patches with all of the logic visible. This is a great idea for examples and tutorials like this one. However, when building interfaces for performance, it is often useful to hide the wires, showing the performer only wht they need to execute the piece. Graphical send/receive is a perfect solution.

Properties of graphical objects

To find these send/receive pairs, just right-click on any GUI object (numbers, sliders, VU, radios, etc) and choose "Properties". You will be greeted with a dialog box with many options, depenind on the object. We're interested in the send receive section. Below is the send/receive section of a "bang" GUI object.

Here, adding a name, for example "go" to the send field. Now our "bang" GUI will send a "bang" to the receive "go". If we create another "bang" GUI object and set it's receive field to "go", the first "bang" GUI will "bang" the second.

Any graphical object can communicate with any other in this way. Send messages fro GUI opbjects can also be received at an ordinary [receive] object as well. The send/receive names simply have to match.

Example patch

Attached is an example of communicating numbers to and from graphical objects across subpatches, in this case to do exactly what I stated earlier, to hide the "guts" of the patch from the user/performer. In this patch, sliders on the front page send values to the frequency of an amplitude modulator (ring modulator) and to the volume of the overall outlut. Two VU's on the front page also receive the signal level from the patch's "guts", giving the performer visual feedback about what's happening to the audio.

For fun, I have added an extra trick, using semicolon delimited messages to send numbers into the Properties dialog directly. See the numbers displayed on top of the graphical sliders as well as the message system under the hood (click on [pd guts]).

 

Tutorial 3 - Audio input and recording

Audio input and output, [adc~] and [dac~]

Audio input and output in PD is done via [adc~] (analog to digital converter) and [dac~] (digital to analog converter). In most cases this is simply a number-by-number mapping to and from physical hardware. Setting [adc~] to [adc~ 3] tells PD to take in audio from the 3rd hardware input. By default both [adc~] and [dac~] use the frst two inputs/outputs.

A simple recorder

To build a recording mechanism we need to steps, audio input and audio writing. We'll assume, for now, using the first two audio inputs, as if you were going to try this patch out on a laptop. The only other object we need is [writesf~], although there are several other ways to write audio in PD (see tabwrite~, soundfiler, and sfrecord). [writesf~] simply writes the audio it receives to disk given a filename with [open filename.wav] and a [start ( or [stop ( message. So the patch in it's most basic form is just:

Note that this gives us no control over the level in (except the hardware level) and no way to do anything except overwrite the same file, filename.wav, over and over. Not very useful.

To fix the problem, we need to insert audio multipliers before the signal reaches [writesf~]. A multiplier of "1" means what multiplying by 1 always means, you get "itself". Multiplying by .5 gives you half, etc. We also want a way to change the filename, the simplest thing would be for the recorder to simply make a ew filename each time you start a new recording. The new, fancy, little hand-held recorders do this but we're going to save you some cash with a free PD solution.

Example patch

Like the patch in tutorial 2, we're going to build a patch with a graphical front end, giving the user a simple interface to interact with. In this case, we want:

1. Ability to enable/control signal mic level
2. Ability to start recording to a new file (value added: something to tell us the name of the new file)
3. A set of meters to show the signal level so we can avoid clipping

So in addition to the basic [writesf~] mechanism we want to create something to control mic levels (a multiplier), something to increment through a set of filenames, and as wtih the Tutorial 2 patch, VU meters to show the audio level.

The fist one is easy, just insert an audio multiplier that can be turned up and down from the front page via send/receive. Here a toggle object, which sends "0" or "1" when off or on, is sent to a [line] which ramps up and down over 200ms. So the level is raised when the toggle is checked and lowered when it is not.

The filename question is a little more complicated but essentially we want to write a new file with a new name each time (avoiding overwriting the previous file), something like soundfile1.wav, soundfile2.wav, soundfileN.wav, etc. So we need our [open filename ( message to change each time, ideally with something that can just substitute a new number at the end of the filename.

The solution is to use [makefilename]. See its help patch for the available options. Here we are using %d to substitute a new number at the end of the filename. Beyond that, this patch is almost identical to the counter patch from Tutorial 1 ("never design what you can steal").

Like the counter, numbers increment within float and this number is added to the end of the filename soundfile%d.wav at the %d position. This filename is then send to [writesf~] as the file to [open (.

Finally, we want all of this information to be accesible via a graphical front end. We want to be able to enable and.or adjust the mic level, we want to see the level in a set of VU meters, we want to be able to enable the recording, and we want to see what filename is curretly in use. This can all be done via send and receive to and from the guts of the path. See attached.