I included the example patcher (grooveplay.maxpat) in the zipped soundfilepatcher archive from Monday.

buffer~

Preliminary stuff first. buffer~ allows you to load a sound file into RAM. You can play it back with a number of objects, get information about it, etc., but it is in effect like sampler memory.

The object takes arguments for buffer name, length (in ms), and number of channels. You “read” files into a buffer (instead of sfplay~’s open), but it is more beneficial to use a replace message. The replace message resizes the buffer to match the length of the sound file loaded.

You can double-click the buffer to see a graphic waveform display of the loaded sound file. The left outlet of buffer will report mouse position (in ms) when you click on the graphic display. The right outlet sends a bang when a sound file is finished loading. This bang is useful for sending to objects that provide info about the sound, and for other uses.

groove~

I just love the name of this object! The groove~ object plays sound from a buffer. It needs an argument for the buffer name to read from, and for the number of channels. The number of outlets depends on the number of channels for playback — there will always be one more than the number of channels. (The last outlet sends out a sync signal, which we will seldom if ever use.)

groove~ takes a signal-rate input for playback speed, expressed as a decimal ratio. Unity playback is the ratio 1. Negative ratios play backwards. I’m scaling a CC and sending it to a sig~ object (converts a float to a signal). The output of the sig~ object is sent to groove~. The toggle can be used to start and stop playback, although it won’t change playback speeds. The extra 0. message is included as a simple stop button.

groove~ has one big gotcha to get it to start playing. You have to tell it where to start in the buffer (time in ms). I’m using the message with “0.” to do that (it’s marked with the rewind comment). If you aren’t looping playback, you’ll need to “rewind” the playback position to play the sound again.

Looping status is set with the loop message. Loop 1 (or true) turns looping on; loop 0 (false) turns looping off. The second inlet can be used to set the minimum loop position (loop start); the third inlet sets the maximum loop position (loop end). If neither min or max points have been set, groove~ will loop the entire sound file.

I’ve zipped the example patcher, CtlnAssign, and a couple of sound files into one downloadable folder.

sfplay~

MaxMSP has an excellent tutorial and help patchers. My example doesn’t try to recreate everything you can do with sfplay~. I’m focusing on basic playback, the loading of files, and how to create a useful start/stop mechanism with the spacebar. Most of the advanced features of sfplay~ are better handled with buffer~ and objects like groove~, etc., which will talk more about.

The heart of the patcher is in the blue box. The object uses an argument to specify number of channels (above 1) — it can play up to 8-channel files. sfplay~ takes an open message to bring up a standard file dialog box. A toggle is useful for starting and stopping playback. 1 starts playback from the beginning of the file; 0 stops. When the file is done playing (either by reaching the end of the file, or by having the user stop it manually) the object outputs a bang out its right-most outlet. The [open Cave_Water_Drops.aif] message loads that file for sfplay~ without a dialog box. This message only works if the file is either in the same folder as the patcher, or in anther folder in the MaxMSP search path.

In this example patcher I’m using the space bar to control starting and stopping of playback, much like commercial audio software. The key object leads to [select 32] (32 is the ascii code for the spacebar). The output of select feeds into a gate object so that I can control when the spacebar affects playback (don’t want the file to start when I’m typing new objects).

The toggle that starts and stops file playback also gates whether the stop bang will get sent back to the toggle. If the sound file reaches its end, the gate will be open and the bang will go to the toggle and reverse its state (showing that the file has stopped playing). If the user stops playback the gate is first closed, stopping the bang from reaching the toggle (which would restart playback).

dropfile

dropfile lets you drag-and-drop files from the finder to load into sfplay~ (or other file-based objects). The right outlet shows the file type that was dropped (could be used as a gate or error check message if you don’t drop a valid sound file). The left outlet gives the full path and name of the file. Sent to an [open $1] message, this will allow you to load that file into sfplay~.

As indicated, this is a scaled-down post so that you have the demo patchers from class.

To use the PolyAudioDemo.maxpat you also need to download SimpleSynthKeith~.maxpat and place both patchers in the same folder.

Highlights

The poly object

The poly object takes incoming noteon and noteoff messages (note number and velocity), tracks them so as to allocate across multiple voices, and makes sure that corresponding noteon and noteoff messages go to the same voice. The incoming note number and velocity messages are tagged and outputted with a voice allocation number. Output = 1 60 127, where 1 is voice number 1 in a polyphonic synth, 60 is the note number for middle C, and 127 is the velocity.

Voice allocated noteon and noteoff messages are sent to a poly~ object that has a synthesizer subpatcher.

poly must specify the number of polyphonic voices to track, and whether to institute voice stealing (non-zero third argument).

The poly~ object

The audio poly~ object requires a patcher that has been designed to accept incoming messages from a parent patcher. It also requires an argument to set the number of polyphonic voices to play, which should correspond to the same number in poly.

Note messages should be sent to a free voice by using the voice allocation number assigned by poly. The message target $1, $2 $3 says to route items 2 and 3 from an incoming list to the voice number (instance of subpatcher) specified as the first item in the list. The formatting of the message is very important — watch out for the comma.

Preset selection messages should go to all instances of the subpatchers (usually), so the message target 0, $1 is used. If the target is 0, the subsequent message is sent to all instances.

The audio subpatcher: SimpleSynthKeith~maxpat

SimpleSynthKeith~.maxpat, and any subpatcher you would load into poly~, must be saved in the either Max’s search path, or saved  in the same folder as the parent patcher. Rookie mistake: trying to load a subpatcher without first saving the parent patcher.

SimpleSynthKeith~ has two gates: one to toggle MIDI input on and off within itself, and one to turn on/off sending of audio output to the dac~. When loaded as a subpatcher of poly~ these gates should be turned off. MIDI input and audio output are handled in the parent patcher. When you open SimpleSynthKeith~ as a standalone patcher, turn on the gates so that you can play and hear the patcher. This feature is useful for trying out different parameters and saving them as presets in SimpleSynth. You can them recall them from the parent patcher.

My delay demo patcher is finally uploaded. It also includes a little section with a degrade~ object. I’m only doing bit reduction with the degrade~ object.

Mr. Olson has prepared a wondrous chiptune demo patcher for 2/24. Download and prepare to amaze and be amazed.

I’ve uploaded a much-improved version of my simple additive synthesizer (2 oscillators). The patcher makes extensive use of send and receive objects, which function to both clean up the spaghetti tangle of patch cords, and provide a means for self-commenting code.

The core of the patcher is a two-oscillator additive synth, with function controls for amplitude envelopes.

MIDI input and other user interface controls, aside from the function editors, are located at the top of the patcher. A MIDI keyboard is used to supply the pitch (as a MIDI note number later converted to a frequency in Hz), and to trigger the attack and release sections of the envelopes. Note numbers from noteon messages are sent via stripnote to the s noteNumber object. noteNumber is received by both oscillator patches. Stripnote also passes the noteon velocity, which is sent to each function editor via s noteOn and used to bang (start) the function. Since each function editor makes use of a sustain point (indicated by the white halo around the dot), a next message is needed to move to the release portion of the envelope. All incoming velocities are sent from notein to the select object. Noteoff velocities of 0 are selected, and the resulting bang is sent via s noteOff to each function editor to trigger a next message. Notice how the send and receive objects are self-commenting the patcher? Since you have to label a send/receive destination, you can use a label that indicates what is being sent. I’ve color-coded all the send/receive objects so you can easily find the connections.

The ratio (multiplier) for the second oscillator frequency can be set with a float, sent via s partialRatio. Overall partial amplitude is addressed similarly via partialAmp. To the far right of the top portion there is also an input to set the overall time length of the function editors (via adrLength). Since the sustain will last as long as you hold down a key, this length only really applies to the attack, initial decay, and release times. The integer is sent to the setdomain $1 message, and the whole message is sent to each function editor.

There are two continuous controllers being used to set the detune amount, and the portamento time (portTime). The top integer of this portion can be used to tell ctlin to listen to a different controller number (119 and 120 work with my nanoKontrol). The cc input is scaled to an appropriate range (0. – 1. for detune, meaning a max of one half step; 0. – 1000. for portamento in ms), and then sent.

The first oscillator is very straightforward. noteNumber is converted from MIDI to frequency (Hz), packed with the current portamento time, and the message is sent on to line~ and eventually to the frequency input of a saw~. The function editor receives noteOn, noteOff, and adrLength messages. Its output is pairs of numbers in line~ format, sent to a line~, and then on to a *~ to control amplitude.

The second oscillator has the exact same function editor controls, but is more involved with regards to frequency. noteNumber and detune are added together and eventually sent to mtof. mtof can convert fractional MIDI note numbers to the appropriate microtune frequency. The detune amount is added to the note number, and the bang message is triggers the + operation when ever the detune amount changes. This allows you to update the partial frequency with detune information even while holding a note.

The detuned frequency is then sent to a multiplication object to be multiplied by the partial ratio. From there, the rest of the patcher is similar until you get to the extra *~ object for scaling the overall partial amplitude (since partials usually have less amplitude than fundamentals).

The output of both scaled saw~ objects are sent via an audio send object (send~) to the same receive~ destination, and then to gain~ object and ezdac~. It’s important to note that audio send~ and receive~ objects must be spelled out in full, not abbreviated as s~ and r~.

I will be posting an expanded explanation later, but for now I’m putting up Michael Olson’s Day 16: Audio Brass Tacks patcher.

Those students looking for add’l software synthesis bang for NO bucks, check out the offer from Native Instruments:

http://bit.ly/zuAPLn

You can get the Kontakt 5 Player, Reaktor 5 Player, and Guitar Rig 5 Player all for free. And they come with sounds.

(if you’ve gotten tired of your DLS Apple Synth)