skeller

Max receives data from an accelerometer on the bell. Data is send via XBee and the X and Y values are used to control the volume mix of 4 samples (similar to a vector synthesizer joystick). Max also receives twitter data from a python script via OSC and that data determines whether Max will play samples from beginning to end or segments of them.

digital-bell-tower

Digital Bell Tower

Meng Qi

theremin

Tobias Reber

Tobias Reber used a combination of algorithmic structure generators/step sequencers, samplers and a granular sampler that are programmed in Max/MSP.

untight-live-at-theaterkapelle-free-download

Untight "Live at Theaterkapelle" (Free Download)

Darwin Grosse

grosse-arpeggiator

ddg.arp

Andrew Benson

I spent 4 days in Pittsburgh in early June attending the 2009 NIME conference at Carnegie Mellon University. NIME is a conference devoted entirely to new interfaces and devices for the performance of musical ideas. The conference consisted of three days of paper talks, poster sessions, demos, and performances. There was also a well-curated gallery show with a number of impressive interactive sound installations. In addition to all the talks and posters happening on campus, a number of us gathered for nightly pitchers of Yuengling and pizza at the local watering hole, the Panther Hollow Inn. I will try to summarize here what I thought were some of the highlights of NIME 2009.

During the poster sessions, where we had an informal table to share info about Max for Live and other projects, I had a chance to see some really interesting projects.  One of these was Langdon C. Crawford's scrappy-looking but impressive MIDI Airguitar controller complete with in-depth Max patch interface for music making with it. Far from being a simple guitar-style interface, Langdon and his collaborators have created a unique controller with its own share of quirks and peculiarities, and its own set of skills that must be mastered in order to use it.


Another project that caught my attention was Randy Jones' expressive multitouch surface controller for hand percussion and other musical applications. I got to talk with Randy a great deal about the project, which began as part of his thesis work and is now being prepared for production as a USB controller device. By using a grid of capacitive sensors combined with fast DSP chip and Jitter-prototyped software, the Madrona Soundplane A tracks the location and pressure of multiple points on its smooth wood-veneer surface. This data can be used to drive a synthesis engine, such as the physical-modelling percussion synth he uses in his demos. Beyond the technical details of the controller, there is a fantastic and expressive feel to it that is similar in many ways to a hand drum. The production prototype also sports a lovely all-wood exterior, including a thin plastic-coated wood veneer touch surface. Keep an eye on the Madrona Labs website for more information on the commercial production and even DIY instructions.

Other highlights include an intricate double slide trombone-style wind controller by José Tomás Marques Henriques, an array of interesting projects from Adrian Freed and the gang at CNMAT, the announcement of OSC 2.0, and the Audio Orienteering project by Noah Feehan from MIT Media Lab. Performance highlights included Chikashi Miyama's kinetic "Angry Sparrow" piece (see video below), our own R. Luke Dubois performing with Lesley Flanagan, and David Wessel performing a new work for the SLABS controller.

I will try to summarize here what I thought were some of the highlights of NIME 2009...

a-look-back-at-nime-2009

A Look Back at NIME 2009

Lilli Wessling Hart

NAMM • Anaheim, CA • January 15, 2009--Cycling '74 and Ableton today announced Max for Live, the integration of Cycling '74's Max/MSP environment into Ableton Live. Available as an add-on product to Ableton's newly announced Live 8, Max for Live permits users to create devices that extend and customize Live by creating instruments, controllers, audio effects, and MIDI processors.

Devices developed with Max for Live utilize the same features as those created by Ableton engineers. This includes UI controls, MIDI mapping, multiple undo, tempo-based effects, sample-accurate automation, and comprehensive file and preset management. Devices created in Max can be shared with Ableton's new web collaboration features. An innovative “preview mode” feature permits editing in Max while devices continue to process audio and/or MIDI as if they were inside Live. When an edited device is saved, it updates in place inside Live's device view.


The devices included with Max for Live illustrate the potential of the integration of the two products. Step Sequencer is a MIDI effect that features four 16-note sequences with adjustable step sizes. It includes unique features such as sequence shift buttons, a random mode, and real-time MIDI control. Loop Shifter is a new type of loop playback device that uses MIDI to change the way loops are played back. It includes automated mapping and playback modes that produce surprising and entertaining results. Finally, a Max for Live extension for the newly announced Akai APC40 transforms the buttons on the hardware controller into a step-sequencer-style editor for Live MIDI clips.

Max for Live features a variety of basic building blocks for creating new devices as well as an extensive set of interactive tutorials illustrating the development of instruments, audio effects, and controllers. 15 new Max objects duplicate the UI elements found in Live devices, manage parameter state, and provide an unprecedented level of control over the Live environment itself.

Max for Live will be available from Ableton later this year. Pricing information will be announced when Max for Live is released.

Cycling '74 creates software for the specialized needs of artists, educators, and researchers working with audio, visual media, and physical computing. Our visual programming tools Max, MSP, and Jitter serve as the creative engine behind thousands of innovative projects.

More information about Cycling ’74 and its entire product line available at https://cycling74.com.

Ableton develops technology to inspire creative people. Since the company started in 1999, Ableton has attracted an extensive and highly committed community of musicians, composers and DJs worldwide. Currently, Ableton counts about one hundred employees in its Berlin and New York offices. The company has received outstanding press, awards and customer feedback since the unveiling of Live in October 2001.

More information about Ableton and its entire product line available at http://www.ableton.com.

Cycling '74 and Ableton today announced Max for Live, the integration of Cycling '74's Max/MSP environment into Ableton Live. Available as an add-on product to Ableton's newly announced Live 8, Max for Live permits users to create devices that extend and customize Live by creating instruments, controllers, audio effects, and MIDI processors. 

announcing-max-for-live

Announcing Max for Live

Gregory Taylor

Now that I've got a nice generative patch and a way to hear it, I thought it'd be nice to make a few improvements and extensions that would let me begin to specify larger structures - to generate instructions to my generative patch, as it were. While I'm sure that the world is full of people who want ways to have the same thing happen again and again, I'd like to do this in ways that offer a little more freedom than that. This short tutorial will add a modest number of these kinds of changes.

LFO Tutorial 1: The Zen of the Silent Patch

Click here for a full-sized version of the patch image.

In the course of playing around with the LFOur - LFOur_vst and LFOur_out patches, I decided that - although I had considerable control over the patterns I could generate from a small number of pitches stored in a coll object - I would like to allow for more variety. In some cases (and working with VST drumboxes what what got me thinking about this), it was great to have a very small number of choices. I could limit those choices by changing the contents of the coll object I used when mapping output or I could experiment with different settings for the notevalue tempi of each of the four LFOs in combination with the rate at which I sampled the LFO output. In the course of experimenting with this, I realized that I could add the ability to work with multiple coll objects to my patch, or I could also consider changing the size of the range of notes in the coll object that I used when sampling (e.g., for an ostinato, the coll would only have two choices when scaling its output).

After some thought, I decided that since neither addition was very complicated, I'd add both options.

First, I'd like to have the opportunity to use more than one coll object in order to vary the set of pitches I use when mapping the LFOur patch's output. I added a single receive object connected to the coll.

Whenever I send the message refer followed by the name of a coll object in my patch to an s ref object, I'll switch the coll that's used when mapping output.

Adding the ability to select a range within the coll object itself involved the addition of two new  inlet objects to the notemap subpatch and the addition of a pair of number boxes to the top level of the patch that specify the low and high output mapping values used by the scale object that is used to map LFO outputs to MIDI note numbers. A nice side effect of this choice is that I no longer care how large the coll object I'm using with the patch is - I can set it to any set of high and low values to work with different lengths for the coll objects' contents (just change the high number) or map subsets of the coll object contents by changing both values (0-15, 8-23, 60-63, etc.). And I have added the two number boxes that set the low and high scaling values to the pattr registry in the patch by giving each number box a scripting name using the Inspector, so that my presets now automatically recall my mapping ranges as part of the patch preset.

The values I'm sending to the two newly added rightmost inlets of the notemap subpatch are used to set the arguments to a  scaleobject. As any reasonably seasoned Max user will tell you, there are two different Max objects commonly used for linear mapping: the scale and  zmap objects (just in case you need to be reminded again that there is nearly always another way to do nearly anything using Max!). While they'll both go a fine job of performing linear mapping of one set of values in a range to values within a different range - in this case, mapping values in the range 0-127 that the LFOur patch sends me to a range that matches the size of my coll object - there's a reason I prefer using the scale object: I can invert the values used when mapping outputs, which lets me count “backwards” through a coll object's contents. So I can also now read my coll object forward or backward.

Note: Another difference between the scale and zmap objects is equally subtle: although the scale object will let you reverse the range values when mapping output, it won't clip output values so that the fall within that range - if you feed it a very high value, it'll faithfully map it waay outside the output range you think you've specified.

The zmap object does clip its outputs, although it won't invert output ranges (Is this a bit of fabled “secret” Max arcana? Not really, but I'm always surprised at the number of people who haven't noticed this). Since I'm using a scale object, I've used the minimum and maximum attributes of the number box object using the object ‘s Inspector to automatically clip my input ranges in my patch. Once set, you cannot type a number less than 0 or greater than 63 into either range number box. This is a trick I use often when patching.

The astute and observant reader will notice that the biggest change in the LFOurGenerator patch has to do with the patching that surrounds the  transport object, and includes a quartet of objects we haven't seen in any of the patches to date: the  timepoint object.

Each of these four timepoint objects takes as its argument a time point, specified in bars, beats, and units - one of the timing formats that Max uses. The objects' function itself is pretty straight-ahead: when the transport reaches a timepoint specified by the argument, the timepoint object sends a bang message. In this patch, The timepoint objects control a couple of things:

 The first timepoint object increments a counter used to step through the presets for the LFOurGenerator patch itself. These presets keep track of the sources, notevalues, and range of values from the LFOur patch to be sampled and used as inputs.

The second timepoint object uses a counter to step through a sequence of numbers used to set the sampling rate of the LFOur patch itself by sending a value to the receive destination L4samp_rate in the LFOur patch. Setting a greater sampling rate means that there is more variety in the sequence generated by any LFO.

The third timepoint object uses a  textbutton object as a toggle, and will alternately send the message refer sequence_1 and refer sequence_2 to the receive object  located in our notemap subpatcher, changing which coll object in our patch is used for note values.

The final timepoint object serves several different functions: The first and perhaps most interesting thing it does is to reset the transport (by sending the message 0. to the right inlet of the transport object), effectively creating an 8-bar “loop” which cycles over and over. But it also controls a counter and coll object pair that sends messages that change the presets used in the LFOur patch to change the operation of the LFOur object while the patch runs. Finally, when a complete cycle of the counter is finished, a bang is sent out the “carry count” outlet of the counter object and used to turn off the transport.

You'll notice that I added a  trigger object directly below the large toggle to initialize the state of all my counters and toggles whenever I turn the transport on, and another toggle that actually turns on the transport. You might want to have a look at the patching around the transport object a little more closely.

If you unlock the patch, you'll also see that I've connected the third outlet of the preset object to the umenu and textbutton objects attached to the second and third timepoint objects in order to have them not be affected when the first timepoint object changes patch presets. The one other thing you might stop to wonder about is why there's a  metro object attached to the transport, and why doesn't it have a toggle switch of its own? The answer is that in order to get a current bar/beat/unit output from the transport object, it needs to receive its own bang message, and that's what this metro object provides. Notice that the metro object sets two attributes: autostart and autostarttime. Setting the autostart attribute to one means that this metro will start any time that the transport itself starts, and the autostarttime attribute tells this metro to always start counting from timepoint 0 when it's started up. This metro is the reason that we can see the bars and beats display updating.

So this patch lets us configure a larger scale generative structure - it uses timepoint objects to set the point at which changes will occur, and uses messages to modify not only the patch itself (using messages to the preset object), but also to modify and set the behavior of the LFOur patch itself.

Of course, you don't have to stop there - you can route the same control information to other parts of your Max patch to control how various VST instruments are mixed, to adjust plug-in settings, and so on. Here's an MP3 example that uses this patch and some things I've added that I'll let you imagine. Sorry about the reverb - I've recently downloaded an Altiverb impulse response from Gol Gumbaz in India that I'm in love with. It seemed like just the thing.

I hope this trio of articles has been interesting and enlightening. While your mileage on the examples I've provided may vary, I'm sure you can create interesting kinds of mayhem of your own based on what's here. So don't fare well, fare forward.


Now that I've got a nice generative patch and a way to hear it, I thought it'd be nice to make a few improvements and extensions that would let me begin to specify larger structures - to generate instructions to my generative patch, as it were. While I'm sure that the world is full of people who want ways to have the same thing happen again and again, I'd like to do this in ways that offer a little more freedom than that. This short tutorial will add a modest number of these kinds of changes. 

lfo-tutorial-3-extending-our-generators

LFO Tutorial 3: Extending Our Generators

David Zicarelli

I'm pleased to announce that Cycling '74 will be hosting its first user conference next year, Expo '74. The conference will run three days from April 22-24, 2009 and will be held at the new (and intensely colored) Mission Bay Conference Center in San Francisco. I'd like to tell you why we decided to put on this event and what you can expect to happen if you attend.

Let me start by saying that I am not a huge fan of meetings, whether big or small. For one thing, I wonder about burning so much fossil fuel to bring people together primarily so they can try to sell things to each other. Another thing that bugs me about academic conferences in particular is that a bunch of people show up, give their presentations, and rarely interact except on an informal basis. I've often felt after attending conferences that it would have been better simply to arrange a big dinner.


Our corporate bias against meetings has meant that, up until this point, we've avoided taking the path of Adobe (whose user conference is called Max, of all things). But over the past couple of years we've come to the conclusion that educated users spread the word about our software better than advertising slogans, so we've decided to replace our more traditional marketing activities in favor of what I like to think of as "social and educational" activities. For example, we now post on average one article on Max techniques and applications on our web site every week. Even more in the social domain, we've begun conducting workshops in places where it would be difficult for beginning users to obtain Max training. Once we did that, more advanced users began to ask what we were going to do for them.

The inspiration for Expo '74 actually occurred a few years ago, when a number of us were invited to participate in two Max/MSP/Jitter workshops sponsored by the Forum Neues Musiktheater in Stuttgart. This was the first time that a substantial crew of Cycling '74 employees had been forced to teach the software together. The experience was delightful and moreover, we were inspired to add a number of cool features to the software based on our interaction in Stuttgart with both beginning and advanced users. Fundamentally, I realized the value in making a real connection with people, beyond e-mail, who were working with the code I was writing. My hardened attitude about conferences was starting to weaken. Unfortunately, the FNM organization no longer exists, so if we are to recreate the experience, we will have to do it ourselves!

We hope this conference will be a chance to strengthen the connections within the Max community -- not just between Max objects, but among people. Our community is incredibly generous with both code and techniques, but we think even deeper levels of connection and collaboration can be established if we get the community together in one place.

We'll be filling in more details over the coming months, but at this point, it's our intention that the conference will feature the following:

An intensive course on Max intended for intermediate users and sessions on specific topics of interest to all users

Presentations for developers wishing to extend the Max environment, as well as presentations by developers who have already created powerful extensions

Individual project consulting sessions to help you move forward on the work you want to do

A "science fair" where you can see demos of cool projects and share techniques and resources

Geeky social and cooperative events inspired by the live patching competition we organized in Stuttgart

An opportunity to hear what about works and what doesn't work when teaching the software

Feedback sessions, so you can tell us what you like and don't like about our work

The basic plan is to run the course in parallel to the developer sessions in the mornings, then get everyone together for larger sessions in the afternoons and evenings. Another thing I should mention: we aren't committing to doing one of these conferences every year (see fossil fuel concern above). So, we hope you'll mark your calendars for April 22-24 and stay tuned for more details about this fun event. As we prepare the agenda for the conference, if you have any questions, please feel to contact the event coordinator, Lilli Wessling Hart.

I'm pleased to announce that Cycling '74 will be hosting its first user conference next year, Expo '74. The conference will run three days from April 22-24, 2009 and will be held at the new (and intensely colored) Mission Bay Conference Center in San Francisco. I'd like to tell you why we decided to put on this event and what you can expect to happen if you attend...

announcing-expo-74-our-first-user-conference

Announcing Expo '74: Our First User Conference

This series of tutorials first appeared on my CreativeSynth.com website between 2001 and 2002. Due to their popularity (especially amongst new Max users), I have moved them to the Cycling74.com website. Read the introduction. 

In the last article, we created a simple synthesizer using basic Max and MSP objects. The biggest problem with that synth was the last ov output control - and an annoying thump in the output whenever a new key was struck. In this, the second article, we will correct some of these problems - and open some new doors.

Output manipulation using Envelopes (part 2)

cs.synth_02, shown below, is a slightly modified version of the original cs.synth_01. If you'd like to download the patch and the supporting object, you can get it here. This synth has a few new options.

First off, the output section has been changed slightly to include a clip~ object. This allows us to prevent sending the sound card anything greater that the normal -1.0 to 1.0 range. This object will clip the audio to          that range, and will keep us away from unwanted distortion and clipping at the outputs. This is a good practice, and will be expanded upon in future articles.

The second, and more important, change is the section labeled "Envelope/VCA Stuff". This section, which only contained simple divider and multiplication object. Now, we are given two controls (for attack and release time), and everything is funneled through an object called ddg.velamp. This object is an encapsulation of some more meaty logic.

Let's pop open the ddg.velamp object and see what is in there...

This object takes three inputs - the note velocity, an attack time and a release time. On the other end, it outputs an envelope signal (you can tell it's a signal by the "fuzzy" patch cable). In between the inputs and outputs, we have to determine trigger and release points, create an envelope and create a velocity-scaled output.

The pink section is a simple evaluation of attack or release events. When a velocity value is input, it is checked to determine if it is greater than zero. In Max world, velocity of 0 is a note-off (or release), while a note-on is greater than 0 (i.e., the attack event). Using a route object, a bang is triggered from the appropriate output.

The green section is the setup for the envelope. First, you will see that the incoming attack and release time values are multiplied by 20 to stretch them out. In the synth patch itself, we are using the default 0-to-127 range for the dial objects. With this multiplication, we will now have ranges from 0 to 2540 ms.

Next, the attack and release values are used to create messages to be sent to the line~ object. The format of a line~ message is "level", where time is optional (and defaults to 0 ms). On the left side of this section, we are setting up a message that will "zero out" the level, then build it up to 1.0 at the selected rate. In line~ terms, this is two separate messages. So, we create a message box that contains two messages, using the comma (,) delimiter.

The funny message that is constructed is a convoluted way of getting the message "0., 1. " to the next message box. This is made somewhat more complicated by the difficulty in creating a message with a comma in it. In order to pass a comma in the message, we need to use the "" slash in front of the comma. Also, make sure that there is a space on both sides of the "," combo - otherwise the slash will be included as part of the prior or next message.

This message "sets" a message box that will be "banged" by the next incoming note-on message. A corollary is available for the note-off, but doesn't have to set up the dual message - and is therefore much simpler. Try to carefully follow this patch to understand this routing.

The output of the line~ object is a ramping signal that runs from the last setting to the new setting. In order to use this output, as well as to still maintain velocity control, we need to scale the line~ output by the incoming velocity. To do this, we capture the note-on velocity (by ignoring note-offs), scale it using the divide (/) object,          then multiply the line~ output by this value. In this way, the output of this sub-patcher will be sensitive to envelope settings as well as velocity.

The final step is the use of the rampsmooth~ object. This object is super valuable - it prevents ramped values (like amplitude envelopes) from changing too quickly. any signal (even our simple sine wave) will thump if the          attack or release times occur too quickly. This object will help alleviate thumping by smoothing any change over a specified number of samples. There is still the opportunity for thumps - especially if you are driving the          outputs very hard. But, in general, a simple rampsmooth~ strapped across a line~'s output will help create a more controllable envelope.

In the main patch, you can see that the velocity, attack time and release times are routed to the ddg.velamp object, and the output is sent to a multiplication (*~) object for output scaling. In this way, we maintain all of the VCA-style control of the original synth, with the new attack and decay times.

This series of tutorials first appeared on my CreativeSynth.com website between 2001 and 2002. Due to their popularity (especially amongst new Max users), I have moved them to the Cycling74.com website.

synth-building-with-maxmsp-2

Synth-Building with Max/MSP #2

Cycling '74

Interview created and produced by Sue Costabile for Cycling '74.


Performance
Mind expansion through Max/MSP.
Interview created and produced by Sue Costabile for Cycling '74.

Cycling74 Perspectives: Kevin Blechdom

Kevin Blechdom: Mind expansion through Max/MSP.

Search Results