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)

Max/MSP has two ways of viewing a patcher,

• patcher view, which we’ve been dealing up to now, and
• presentation view

Presentation view provides an alternate way of viewing your patcher information. Patch cords do not show at all, and you can decide what (subset) of objects appear in presentation view. You can even rearrange the layout of your objects, and resize them.

Open the synchMetros patcher (downloaded in an earlier post). The patcher opens in patcher view. Along the bottom of the window is an icon that looks like a projector screen. Click it to go into presentation view. The patcher layout changes, even including colored background panels (the panel object) in very garish colors and 90s-style button shading.

You can unlock in presentation view to rearrange and resize objects.

Switch back to patcher view and unlock the patcher. Objects with a pink halo will be included in the presentation view. Select an object and choose “include in presentation” from the object menu (or contextual menu) to add an object to the presentation.

If you add new objects in presentation they will show up in different places in patcher view. Also, some resizing properties and location do not transfer between presentation and patcher views. That is why there are the two small panels off to the side of the patcher in patcher view.

Download the encapsulation and ccAssignNew patchers. Keep the ccAssignNew patcher in the same folder as encapsulation, or if you want to use it over and over in your own projects, store ccAssignNew in Max/Cycling ’74/max-externals.

Encapsulation

Encapsulation is the process of creating patchers within patchers. It can help to organize your overall patcher layout and function, and create shortcuts that you can reuse in multiple patchers.

The patcher object

Inserting a patcher (p) object creates a new patcher window. The new patcher window functions like any other patcher window, but it is part of the parent patcher. In a locked patcher, double-click the p contlassign object. The window that opens is very similar to the ccLearn patcher from the previous post. The difference is that contlassign has new objects: an inlet and two outlet objects.

Inlet objects within a patcher create object inlets. You use these to pass messages from the parent patcher to the subpatcher. Be sure to open the inlet inspector and add a helpful comment. Comments show up as popup help when you mouse over an inlet. The inlet of contlassign is to send a bang to turn on the toggle and open the gate to set the CC number to the currently changing CC.

Outlets send messages from the subpatcher to the parent patcher. Be sure to comment them as well. The two outlets send the set CC value (the position or value of the controller) and the CC number.

Patcher objects are useful if you think you might want to edit the subpatcher from within the parent patcher. But the contents of the patcher object are only usable within the single parent patcher that the object is in.

Subpatchers as objects

You can save any patcher and then use it as an object within another patcher. Look at the bottom part of encapsulation. ccAssignNew.maxpat has the exact same contents as contlassign, and functions in the exact same way. But since ccAssignNew.maxpat is a saved patcher, it can be used repeatedly in a patcher without having to type anything each time it is inserted.

The only small difference is that the inlets and outlets are not numbered. Their relative position is still important, and corresponds to their placement on the object.

Object subpatchers have to be stored in either the same folder as the parent patcher (the parent patchers has to be saved for this to work), or in a folder that Max searches. If I plan on using an object in many patchers, I store the object patcher in Max/Cycling ’74/max-externals with the other Max objects.

The ccLearn patcher can be set to listen to any continuous controller (CC) input, and then set itself to always listen to that CC input.

Listening

The listening section is based around a ctlin object with no arguments. Without arguments, ctlin listens to all CC numbers. The middle outlet sends the current CC number.

Learning

The toggle opens a gate that allows the current CC number to pass through. When a CC number passes through the gate the trigger (t) object

• outputs a bang that turns off the toggle (bang reverses a toggle state),
• outputs the CC number to a set $1 message that is passed to another cltin object. This step causes the second ctlin object to listen for the new CC number (until another CC number is passed through the gate),
• outputs the CC number to a number box for viewing, and
• outputs the CC number to a print object.

To follow up on my last post on my global synch’ing metro patcher, here’s an explanation.

Transport

Since I’m using musical time, I have to use the transport. I want to be able to start and stop the transport, and to change tempo. Rewinding isn’t completely necessary, and I don’t care about transport location, so I’m not reporting measure | beat | tick values.

Global Metro

The global metro sets the “quantization” interval, or the time interval that synchronizes time changes in the other metros. The initial value is the quarter note (4n) because the loadmess object sends a 2 to umenu, choosing the menu item at the index location 2 (the third item in the menu). Loadmess sends the argument as a message when the patcher is finished loading. It is a great object for setting initial values in number boxes, umenus, and other changeable user-interface objects.

The global metro sends a bang at the specified musical time interval via a send (s) object to any receive (r) objects with the same argument (syncBang).

Playback Metros

Each playback metro looks familiar, except for the way time values are sent to the metro. Time values are sent from the umenu object to the right inlet of message box. The time value is stored, but not outputted from the message (because it comes in the right inlet). When the message receives a bang via the receive syncBang object, it is transmitted to the metro object to change the playback speed.

The patcher is not perfect. Since metro objects update their tempo on their next bang, you can still get the metros out of sync. But it is easier to make changes to the metros all together.

Here’s a quick post of the global synch’ing metro that I demonstrated. A more detailed explanation will (hopefully) come later, but for now…

synchMetros.maxpat

Download the demo patcher, MusicalTime1-day06.maxpat.

New Objects and Messages

The transport object. The transport object is an object that allows for time to be represented musically in bars:beats:ticks. You can control the transport window (Extras | GlobalTransport) and control the transport with start, stop, and rewind buttons, and set the tempo. You can also use a transport object in your patcher and communicate with it directly. Changes to the transport object show up in the GlobalTransport window.

The umenu object. The umenu object creates a drop down menu box. Choosing a selection causes the index location of the selection to be sent out the left outlet (an integer), and the actual text of the selection is sent out the middle outlet. You populate the umenu by editing the the menu items attribute in the umenu inspector. Separate menu items with a comma.

The message object with a changeable argument. The message object usually sends a fixed message, either by clicking on the message object, or by triggering it with another message. The $1 argument ($number) takes an incoming message (the number indicates which item in a list) and replaces the $, outputting the message with the other text in the message box.

Attributes. The “at sign,” @, used typed in the manner of an argument in an object box sets an attribute for the object. Attributes are often set in the object’s Inspector panel, but they can also be set directly in the object.

The Basic Metro

The first part of the patcher is a copy of our basic metro usage triggering a note number to makenote. You will probably have to enter in a number larger than zero to hear the output well. Time is expressed in milliseconds for both metro and makenote, with an integer object allowing for the initial time arguments to be changed.

The Transport

The second part of the patcher introduces the transport object. If you open the GlobalTransport window you can see that your actions on the transport object are reflected in the GlobalTransport window. The toggle object starts and stops the transport in the same manner that it does with a metro. (specifically, any non-zero number starts the transport; zero stops it.)

If you send a bang message to the transport, it will output its current state. The demo shows the output of bars, beats and ticks in the three integer boxes. The transport does not automatically, or continuously report its location or any other state. You have to trigger that output with a bang message.

If you send a number to the right-most inlet of transport, you set the transport location in ticks. The demo uses a 0. to rewind the transport to 0 | 0 | 0 (tick 0).

The message “tempo” followed by a number sets the transport’s tempo. You can see the integer sending the number to the message box that contains “tempo $1.” The message to the right is just there to show you the output of the tempo $1 message. Sending a message to the right inlet of a message object changes the message without outputting anything. It’s being used as a display source in this part of the patcher.

Musical Time

When you are using a transport in your patcher it opens up the possibilities of expressing time in formats other than milliseconds. The MaxMSP reference pages list all the possible time formats. Most of our usage will focus on the musical time format. Musical time expresses durations in note values, such as 4n equalling a quarter note. Any object that makes use of time arguments or messages, such as metro and makenote in our patcher, can accept a musical time value message/argument.

This part of the patcher is also using the bang out of metro to have the transport regularly report its current location.

Running the Metro in Synch with the Transport

This last part of the patcher dispenses with the toggle to start the metro, setting the metro to start and stop with the transport. The synchronization is achieved by the use of attribute settings to the metro object.

To make this part of the patcher work as expected, rewind the transport by clicking on the 0.

The metro object has a duration argument set in musical time (4n), which is followed by an attribute setting. The @active attribute is set to true (1), which means that the metro will start when the transport is started. (This is a change from in class. The @autostart attribute expects an @autostarttime attribute. The @active attribute just tells metro to start and stop with the transport.)

The final addition is a umenu object to send changes in musical time durations to the metro and makenote objects.

The example patcher from Wednesday is uploaded (cleaned up a little bit). Here are some notes about it.

Basic MIDI note input and output

First, the patcher has a toggle/gate added so that MIDI input isn’t always passed to the Apple Synth (or anything else). The red box is a toggle to turn MIDI note output for this part of the patcher on. You’ll see the button light up at the bottom of the section if notes are being passed to the output. You can ignore the grayed out area and imagine that the outputs of the number boxes are going directly to the noteout object. Be sure to turn it off when you work with the other patchers.

Play Random Notes with Adjustable Duration and Velocity

The random object with an argument of 128 will randomly play all 128 possible MIDI notes. You can adjust the time of the metro with the integer box input, and you can control velocity of the notes with either the slider or a MIDI controller Mod Wheel. The makenote object accepts (from right-to-left) arguments for duration and velocity. It’s inlets (also right-to-left) accept duration, velocity, and note number. Note number triggers makenote to generate a noteon message, followed by a noteoff message after the appropriate duration. At a minimum, note number and velocity output need to be connected to noteout.

Play Notes from a Chord, in Random Order and Transposed Based on MIDI Note Input

The table object is new. Double-click the object in a locked patcher to open (or CMD-double-click in an unlocked patcher). Values (y) are stored at memory locations (x). The random object is now sending memory locations (0 – 4, 5 total) to the table, and the table sends y values (in this case, Dom9 chord tones) accordingly. You can drag values around in the table to change to chord into anything. If you go beyond 5 chord tones you will need to increase the range of the random object to correspond. The y output of the table gets added to a MIDI note that you play from a controller. If you play nothing, middle C will be used. You should know that if you played anything using the first part of the patcher (the basic input), it will also get sent to this add object. Unless specified, notein objects are always listening for input.

Select the table object and open it’s Inspector. (There are many ways to do this. The quickest is to control-click on the object and choose Inspector from the popup menu.) You’ll notice that you can set the object to save the table data with your patcher (turned on), and you can set the range of the table (y values) and the size of the table (x values). Close the inspector window when you’re done.

Right below the notein object is a stripnote object. Stripnote looks at the note number and velocity, and only passes through noteon messages (note numbers accompanied by non-zero velocities). It “strips,” or blocks noteoff messages. The purpose of stripnote is to block noteoff messages from creating extra data for your patcher.

To work, you have to connect note number and velocity from a notein object to stripnote. Without a velocity connection all notes will have zero velocity and nothing will get through. Not connecting the velocity inlet is one of the most common mistakes when using stripnote.

Choose Between Playing Chord Tones in Random Order, Ascending Order, or Descending Order

The new additions to this patcher are a gswitch2 object (graphic switch with 2 outputs) and a counter object. You can switch outputs (which you will see graphically) by clicking on the gswitch2 or by clicking the toggle that goes in its left inlet. Its right inlet has the data to pass through, and the left inlet controls the output destination (the left inlet still makes the object “do its thing”). The counter is mostly self explanatory. The toggle can switch the direction of the counter (0 = up; 1 = down). The counter counts any event in its left inlet, and outputs the current count.

“Steve Reich Phase Generator”

This last patcher is cleaned up from class. It takes the counter output and splits it in two. One output passes directly to the table object, and the other output goes to an addition object for offsetting the count (the phase of the pattern). The output of the add object goes to a modulo object (%), which divides the input by the argument and outputs the remainder. It keeps the output between 0 and 1-less-than-the-argument (or right-inlet input).

The problem with the class patcher was that I used two counters, and I didn’t bother to synchronize their starting counts when I added the second. Using and add offset keeps the two iterations of the pattern in synchronization.

You can experiment with the table values and the number of notes in the pattern, and of course the offset. Reich’s phase pieces work by having two instruments play the same pattern. After a number of repetitions, one of the performers shifts their pattern relative to the other performer, creating a “phase” difference, or phasing. With each change in note offset you get a different combination pattern.

Happy Max’ing!