Duffield

SOMO uses multiple XBee Series 2 radios to transmit motion data into Max and Ableton Live. The system is designed to control other applications via MIDI and Max, or send data via UDP into Max For Live Devices. The parsing of the incoming data is a modification of Andrew Benson's Sensor Box library. All calibration, event detection and state / preset management is also done in Max.

somo-by-sonicwear

SoMo by SonicWear

André Rangel

Emotiv/EPOC headset data is sent to MAX using OSC. Then using Jitter.GL objects a spiral was rendered in real time on a display placed in front of the user. Simultaneously, using a meta-programming approach, MAX generates a .pdf file with a vectorial version of the same spiral.

eegspiral

EegSpiral

diablodale

dp.kinect is a native external for the Kinect which can be used within the Cycling ’74 Max development environment to control and receive data from your Microsoft Kinect.

Full details, beta releases, downloads, etc. are at http://hidale.com/dp-kinect/

It is based on the Microsoft Kinect SDK.

Depth, color, playermap, infrared, and accelerometer data streams are available

Speech recognition and sound position streams are available

Pointclouds, face tracking/modeling streams are available.

Supports multiple Kinects on the same PC.

It was developed and tested primarily with Max 6.x. Casual testing also demonstrates it works on Max 5.1.9.

There is good compatibility with the output of the external as compared to my other external jit.openni. All output is supported and should be equivalent except the optional joint rotations are in a new format.


dp-kinect-external-using-microsoft-kinect-sdk

dp.kinect:  external using Microsoft Kinect SDK

kyleevans1123

A microcontroller transmits sensor information from the CRT to a computer. The data is interpreted and used to control multiple sound synthesis techniques all within Max. The resulting audio signal from Max is amplified and used to drive the yoke of the CRT creating the visualizations. 

derastra

de/Rastra

Justin Sheriff

word-sequencer

Word Sequencer

Julien Bayle

Thanks a lot to C74 & Jeremy Bernstein for his last extensions around ID persistency in livesets

lfo-2-0-for-ableton-live

LFO 2.0 for Ableton Live

Dan Nigrin

Party Favor is a software application designed to work with the Where's The Party At (WTPA) bendable 8-bit DIY sampler, available at http://narrat1ve.com.  It allows you to more easily record audio samples from your computer to the WTPA, and also allows for easier control and visualization of its many effect and editing functions.

project79-party-favor

Party Favor

oli larkin

project1

pMix / int.lib

David Zicarelli

Lilli Wessling Hart

Nine years ago, Robert Henke told me about the edit button.

Robert was in Anaheim, giving amazing Live 1.0 demos non-stop at Ableton's first NAMM booth, and before the last day of the show, we were chatting in the topiary-enhanced parking lot of Stovall's Inn. Having used Max to prototype some of the first effects included with Live, Robert told me he wanted to be able to reprogram his effects on the fly, without stopping the music, just the way everything else worked in Live. At that time, the reality for Robert would have involved translating his revised patch into a C program and rebuilding a new version of Live. This was not exactly the real-time development cycle he was used to as a Max user.

At the time, I told Robert I thought his idea was cool and that we should make it happen. But then I began to immerse myself in the details. Would we have to shoehorn the entire Max environment into Live? If not, how could you edit a patch without hearing it? None of the alternatives seemed terribly attractive. Brooding quickly set in. Fast forward nine years. After a lot of negotiating, specifying, and programming, Robert's dream is becoming a reality. It seemed appropriate to reflect on this newest evolution of our software, and why it has caused my mood to brighten considerably.

The Max device (Degrader) comes with an edit button, unlike the built-in Live device (Erosion).

From Ableton's perspective, Max is the meta-feature. Live's limits are now your imagination's limits. (Who knows, maybe they won't need to add any more features!) But what it does Max for Live mean for Cycling '74 and our users? And why did we want to integrate Max into another piece of software?

As someone whose primary career interest has been software user interfaces, I have to say at the outset that Live has been an ongoing inspiration since I first saw it. The important thing for me is Live's recognition that fluency was a fundamental goal in an interface for creative work. Particularly with version 5, we've tried to incorporate lessons from the Live interface into Max.

After Live appeared, it soon became clear that I wasn't the only one who was impressed. Live has become a preferred tool of many Max users. Live's performance orientation attracts a similar community to ours. And here's a insider tip: Ableton's MIDI, plug-in, and ReWire implementations were always the most stable we dealt with, and we actually knew people who were using the two programs together with success, on both Mac and Windows. That meant we could imagine that an integration project would have a good chance of actually working when we were finished with it!

Ultimately, it came down to this: my Cycling '74 co-workers and I have come to believe the unique thing we have to offer the world is fundamentally about programming. In other words, we want to make edit buttons, and if we can put them in places where they have never existed before, all the better. It was clear to me that Ableton understood what it meant to have the Max environment work with their software. They weren't just talking about more plug-ins.

We've been working with Ableton for more than two years to bring Max and Live together. From the outset, our goal was to create the concept of a dynamic Live device that would make the application itself seem editable. The result is not just another plug-in specification but an entirely new kind of workflow that manages to combine the interactivity and fluency of both applications without compromising anything.

Working on a complex task with another company separated by over 5000 miles and a nine-hour time difference has been an interesting challenge. Time and distance were not the only issue, however. Even though we respect each other's software tremendously, the cultures of Ableton and Cycling '74 are, within the narrow confines of audio software companies, pretty divergent. I suppose I should be careful in making comparisons between the two organizations, but I think it would be safe to say that Cycling '74 operates in a manner that, by comparison to Ableton, could be characterized as complete and utter chaos. Yet for me at least, the experience of getting to know another company and its people has been intensely rewarding. Since December 2007, when Max for Live was first demonstrated (and yes of course, it crashed!) at an Ableton company meeting, the Cycling '74 office began to receive requests for Max authorizations from Ableton employees. That was an encouraging sign for me that maybe we were on to something. For the past several years, we have actually managed to infiltrate the Ableton office in Berlin with one of our developers, Jeremy Bernstein. In retrospect, even with all the other pieces of the puzzle falling into place, it's hard to imagine how we could have accomplished this task without Jeremy being in the right place at the right time.

Even Max users who never end up with Live have benefited from this project. In addition to some of the Live-influenced changes we made to the UI design, there were features we developed for Max 5 specifically to address challenges of Live integration. For example, given the size constraints of the Live device view, we needed a better method for displaying a compact interface that wouldn't distort the logical structure of a patch. The result was presentation mode, which turned out to be a dramatic improvement for UI design for any patch. The task of integrating Max into Live has already prompted a number of innovations within the Max environment and I can confidently predict more will be forthcoming.

Finally, I want to leave you with a Max-centric perspective on what this project represents.

The most obvious thing you are probably seeing as a Max user is the ease with which you can get your Max stuff into Live, as well as share it with a new user community. But that is not the whole story. Instead of thinking about what Max is going to do for Live, think about what Live is going to do for Max. With this integration, a programming environment has just gained a set of powerful composing and performing tools. In Music-N terms, Max supplies the orchestra while Live holds the score. The "score" however is not just MIDI notes. It can be audio, triggered and manipulated in all the sophisticated ways Live provides. Or it can be automation, drawn inside Live and fed to Max as sample-accurate audio-rate ramps if you like. It's equally possible to work the other way, where Max represents the score and Live represents the orchestra.

Those are just the raw capabilities. The real magic happens when you see how it can all work together. Because we started with the requirement to support dynamically changing devices, your "score" and your "orchestra" will evolve together seamlessly. For example, if you edit a device and add a parameter to it, you won't lose the automation data you've already created for the device's existing parameters. Then there is something we have been calling preview mode. Preview mode pipes audio, MIDI, automation, and timing from Live to Max (and back to Live) while you are editing your device. The result is a sound design process that feels completely integrated from the highest to the lowest level in a way nothing else has before.

Once you experience this integration, I think you will see how it has the potential to change the typical usage patterns of both applications. Max is the ultimate workaround for out-of-the-ordinary things you need to do in Live, while Live supplies the sampling and granular audio triggering Max users often find themselves constructing. Our new Live-inspired Max UI objects, with their effortless parameter management, tie everything together, and then you save it all into a single document, ready for tomorrow's creative explorations.

That, in a nutshell, is why I like edit buttons.

David Zicarelli gives some insight on the decision to integrate Max within Live...

my-perspective-on-integrating-max-and-live

My Perspective on Integrating Max and Live

This article provides a brief tour of the features we've added to Max for creating Live devices. If you're familiar with our old plug-in development objects, we hope you'll notice the major improvements we've made. If you're new to creating Max content for audio and MIDI processing, we hope this tour will give you a flavor of the tools that will be at your disposal when Max for Live is released later this year.

Please note, the information presented here is preliminary and subject to change.

With Max, you can design an interface that will appear in Live's device view, a unique advantage over VST and Audio Unit plug-ins, whose custom edit screens appear only in separate windows. This provides immediate access to your device's UI, but the device view is somewhat constrained in terms of onscreen dimensions. This is where Max 5's presentation mode feature will come in very handy. You'll be able to arrange the elements of your interface using a device view template without messing up the patch you've created.

Patching and Presentation Modes in Max and Live. Note the horizontal line that shows the boundary of the Device View.

Max for Live introduces a new set of UI objects specifically designed to emulate the look and feel of the Live interface. But the beauty of these new objects is more than skin deep -- they share the rich set of features built into Live's native UI controls, including:

MIDI and keyboard assignment via simple point-and-click

descriptive text in Live's info view on mouseover

contextual menu for viewing automation for the UI control

automatic color updating when the user changes the Live color scheme

Live-style automation recording and playback, including the display of automation values superimposed on preset value

Some of the new Live-esque Max objects for building interfaces

Since all Live device editing is done "in place" you can save your device in Max and immediately see how it looks in Live. The Max toolbar for a device patcher contains a new button for activating Live for this purpose.

Devices interact with the host environment by means of parameters. A parameter describes data that represents something about how a device will do its job. For example, if you have a device that uses a live.gain~ object to change the output level and a dial to change modulation frequency, you'll have two parameters, one for the gain slider and one for the dial.

A patch with a gain slider and dial, along with the corresponding parameters displayed in Live's automation editor

One of the primary advantages of the new UI objects is that parameters are built-in, so no patching is required to connect a dial with an object that manages the parameter state for the dial. You can also use classic Max UI objects in your Live device, then bind it to a pattr object if you want the UI object to display a parameter. Since pattr objects can refer to other objects by name, no patching is required in this case either.

Use a live.dial or a pattr plus classic Max dial? You decide.

Parameters will have a default name (based on the scripting name) and range, but these are all easily changed within the inspector window.

Long Name sets both the name that appears below the dial and the name that appears in Live's automation view

Range/Enum sets either a minimum / maximum or a list of possible values

Steps sets the precision of the dial when you drag it (or you can use the keyboard to enter any value)

A number of common unit display styles are built into the parameter system, including exponential, dB, time, and L-R panning. These built-in styles eliminate the need to translate between displayed values and the values you use in your patch. There is also a provision for defining custom unit mappings. To configure parameter settings for a pattr object, just open the object's inspector, check Parameter Mode Enable, and the parameter attributes appear.

The new Parameters Window provides an overview of the parameters currently defined for your device, whether they are built into the UI objects or defined via pattr objects. For automation editing purposes, parameters can be one of four types: integer valued (discrete), floating-point valued (continuous), enumerated, or "blob" which designates a parameter that cannot be automated but will be stored in presets. Parameters that are not automated can be single values, lists, or strings -- any type of data you can store with a pattr object.

If you'd like to receive parameter automation data as sample-accurate audio-rate ramps, you can use the live.param~ object, which refers to any pre-existing automatable parameter by name. With live.param~ you can experience the fun of using automation data for synthesis control.

Parameter automation data in a playing Live track is sent to devices you are editing in Max via the preview mode feature.

MIDI MIDI input and output in a Live device uses the same set of MIDI objects you're familiar with in Max. You use notein / noteout / ctlin / ctlout etc. for higher-level MIDI message access, and midiin / midiout for low-level access. 

MIDI processing in Live should look familiar to any Max user

Using Preview Mode, MIDI input and output continues to work within Live as you edit your device in Max.

The Max 5 tempo-based timing objects work seamlessly with the Live transport, simplifying the creation of tempo-synchronized MIDI and audio effects. Here's an example of a simple audio delay that uses tempo-derived values using the delay~ object.

As with MIDI and audio, Live timing information is sent to Max when editing devices when using preview mode.

The live.step object handles the storage and editing of up to four sequences containing note, velocity, and duration information at each step. Each sequence has an independent time scale specified in metrical time units. The live.step object can be driven by a Live-synchronized metro object, and the step sequencer will output note event values occurring at that time. The editing interface uses modifier keys so all parameters of an event can be edited simultaneously. You'll be able to use live.step in any Max project, not just inside Live devices. 

A small part of the preliminary live.step help file

In addition to the objects we've described here, Max for Live will introduce a Max-based API for controlling and extending Live itself through the live.object, live.path, and live.observer objects. We'll preview these objects in a forthcoming article, but we hope the features we've described have you thinking about the possibilities for Live devices you'll be building in the near future.

Search Results