Also, we will only be posting on weekdays – it is skiing season, and I want everyone to be able to hit the slopes…

In other words, it uses my webcam to do creepy and flaming images of myself. I use pretty elementary techniques, so it should be pretty easy for everyone to follow. But I happen to really like feedback, and the results of this are pretty fun.– [ddg]

• Follow the Forum discussion thread to hear about people’s experiences and share your own.

Day 1

I’m kicking this off with a very simple jit.pix patch that I use an awful lot: a patch that does threshold-based binary sampling, then provides offset and jittered feedback.

• Download the Patch

Day 2

The super-secret Cycling ’74 algorithm has chosen me today, and I’m going to throw another Jitter patch into the mix (A note to gen~ fans: It’s just the luck of the draw that we started with two Jitter patches in a row. Don’t despair – there is plenty of audio fun on the way). Today’s jit.pix patch uses very simple means and makes extensive use of the fact that Jitter gen objects work with floating point data in the range of 0. – 1.0 when addressing the position of a pixel and sampling it. When combined with a few trig objects and the ability to sum, wrap, and fold data, there is room for all kinds of warpy fun.

To experiment with using 32-bit float precision in the jit.pix object, just add an attribute to the jit.pix object so that it reads [jit.pix @precision float32], and you’re good to go. Quite a lot of the adorable cruft that I found so fetching about the patch will be gone, but you may find the smooth results considerably more to your liking. In many cases, they *do* look more like a funhouse mirror. Please enjoy this patch responsibly. — gregory

• Download the Patch

Day 3

This patch does a kind of gritty Buffershuffler-esque reordering of the last bar of audio. I’ve hard coded it with crusty old drumLoop.aif to reduce clutter in the patch, but you’ll be able to pretty easily open it out to other files or live input.You’ll need both Overdrive and SIAI on so that the phasor~ @lock is steady. HAPPY PATCHING!!!!!!! — Andrew

Next steps to take in its evolution could be:

• adding variation to the amount of history being collected
• auto changing the number of steps
• adding an envelope to each step
• changing the direction of playback of a step
• copying out parts of audio history into other buffers so that you build up a more diverse history of audio

• Download the Patch

Day 4

Here’s my bunt for all the noobs in the house. This patch is so simple, don’t even look inside! OK, you can look. You’ll see how some really useful things can be super easy in gen.

If you’re on the move with your camera, got your exposure set on your highlights, but the image is still too dark, here’s a quick way to “brighten things up” that’s safer than boosting brightness.

HP! < -- Les

• Download the Patch

“Petal Ignited” is the first release by Springs Period. This is heavily improvised abstract electronic music with a free-jazz bent (Cecil Taylor was a big influence on it). The recordings are all live Max/MSP performances of the compositions, using a performance patch that includes modified “chuckers” and granulators to manipulate pre-recorded samples, generative midi players, and synthesis within Max (thanks to the wonderful book by Maurizio Giri and Alessandro Cipriani for help with the synth-building).  The palette is minimal, with the idea of a small jazz combo in mind, but using the treated samples and synthesis within Max in place of the traditional instrumentation.

The track “Cadenza Antenna” is currently available for free download from the Bandcamp link provided.

The jit.pix-based patches we created in our last tutorial do cool things and use patching techniques that will probably be accessible to the average Max user, they’re not all that they could or should be as Jitter Gen patches.

Don’t get me wrong – they make sense and introduce the idea of swizzling data from a vector in the Jitter Gen world. And they work just fine as patches. But one of the things that’s really cool about working with Jitter Gen objects has to do with working with vectors as you patch.

In the Jitter Gen universe, the vector reigns supreme, and we’re going to take this tutorial to get you used to the idea of thinking in terms of vectors as collections of data (as opposed to the individual bits of data we worked with in the first of these two tutorials), and show you how to patch more fluently and efficiently.

• Download the patches used in this tutorial.
• Read Part 2a: The Joy of Swiz

If you’re a beginner, thinking in terms of vectors involves developing some simple habits of thought about how to combine, split, and recombine data as you patch. To help you along, we’re going to take some of the patches we created in Gen Tutorial 2a and rewrite them so that they make use of vectors and are more “gen-like” and efficient. In many cases, the resulting patches will be a good deal more compact.

One of the first things we mentioned in describing the Jitter family of Gen objects is that the jit.pix and jit.gl.pix objects both operate on matrices that represent 2d images.

As a result of their image orientation, these two objects allow us to do something interesting – when we work with vectors, we often don’t need to use the vec operator at all when patching. In some cases, we don’t even need to swiz out individual bits of data. If we operate on aggregate data, we can take example of some special features of the jit.pix and jit.gl.pix objects.

My First Vectorization

In the Gen Tutorial patch colormap_3a, we took a patch that originally operated on aggregate input data and swizzed out the individual color values (r, g, b, and a) in order to be able to set parameters for the red, green, and blue planes individually for greater variety. Here’s what’s inside of the colormap_3a tutorial patch’s jit.pix object:

View the full-sized screen shot.

You’ll notice that the patch is composed of three sections, each of which has a swiz operator at the top. When a new matrix/vector arrives in the in 1 input object, the red, green, and blue values are unpacked/swizzled.

Each of these values is a floating-point number in the range 0. – 1.0, and the three portions of the patch process each color value independently of the others using the same logic.

At the very bottom of the patch, you’ll see a vec operator, which we used to pack the individually manipulated parameter values back together into a vector for output.

When we did all this duplication, all we needed to do to accommodate the additional channel processing was to change the names of the param operators when we duplicated the functionality from our earlier tutorial patch.

That’s fine as far as it goes, but it doesn’t go far enough.

So far, I’ve talked about the swiz/vector pair as operators that work like the Max pack and unpack objects – they provide a way of taking a group of data and breaking it up into individual pieces that you can modify individually and then repack and send on their way. Introducing the process in terms that most Max users can quickly grasp may make experimenting in Gen seem a bit less scary, but it’s not the whole story. The patches in Tutorial 2a were correct and worked properly, but they didn’t take full advantage of the ability of working with vectors in Gen.

It’s been my experience to date that people encountering Jitter Gen objects for the first time initially find vectorization confusing, but it’s really not that difficult to get used to. The original patch is a perfectly legitimate way to do color mapping and it will work fine when used inside of a Gen patch. But look more closely – you’ll notice that there are three collections of Gen operators that are performing the same kinds of operations on the red, green, and blue portions of each pixel in the image.

Even though we might be working with different parameter values and settings for function and inversions for each of the three colors, the calculations we perform and send to the vec operator are the same in each case – only the parameter names are different.

When we work with vectors in Jitter Gen objects, we can combine the set of three similar calculations into one calculation where all three color channels are processed in tandem by treating them as a vector (you might want to think of the vector at this point as a list that contains three values). When we do that, each Gen operator down the line then performs a calculation on each of the color values contained in the vector. Once we regroup things in this way, each parameter in our our patch will take three three-item lists as inputs, where each list contains the parameter values associated with each of the three colors.

So how do we do that? First, we modify the param objects that provide the interface to the patch. In place of the three param objects for the modes we want to apply for each color, we create a single param object with three arguments (param mode 0. 0. 0. ). This operator describes the vector we’re working with as having three items and also sets their default values. Similarly, we group the amp parameters that set the values we’ll feed to the sine or cosine operator (param amp 2. 2. 2. ). Finally, we can replace the inversion parameters with a single param object with three args that will, by default, set our patch to pass its input in unaltered form (param invert 0. 0. 0.).

Tutorial patch colormap_3b shows what our vectorized patch looks like. It’s a lot simpler, once you understand how we can combine operations into vectors.

In addition to our combining operations into vectors, you’ll notice that the vectorized patch no longer contains swiz or vec operators. You’re seeing a neat feature of the jit.pix and jit.gl.pix objects in action – since we’re swizzing out the red, green, and blue values as a single vector and operating on that vector, we don’t really need to unpack (swiz) or pack (vec) it up – we just pass the vector through the patch logic and output the result.

The clever reader may be wondering why it is that there’s no reference to the image’s alpha channel in sight anywhere in the patch. That’s because the jit.pix object has a particularly useful feature – If you send a three-element RGB vector to the out 1 operator, the jit.pix object will convert it to an RGBA value by automatically adding an alpha channel with a value of 1.0. Sure makes things easier, doesn’t it?

Welcome to the second in a series of “drive-by” tutorials – quick introductions to the world of Max Gen objects. While the Gen world is deep and subtle and you may eventually find yourself thinking about things like polar coordinate conversion, dot products, and other bits of arcana, you can still do some rewarding things armed with a few basic concepts and the will to play.

• Download the patches used in this tutorial.
• Read Part 2b: Adventures in Vectorland

Reading This Tutorial (And The Next One)

You’ll notice that this is Gen Tutorial 2a, and that it showed up alongside its fraternal twin Gen Tutorial 2b on the very same day. They’re closely related, but very different. In this first tutorial, we’re going to introduce some basic concepts about working in the Jitter Gen environment in ways that closely resemble your experience in the Max world.

Our suggestion is that you go through Tutorial 2a, learn about swizzling, play around with the patches and then dive right back into Tutorial 2b. The second part of the tutorial takes the concepts you learned and the patches we showed you and rewrites them with more efficiency by making use of the vector nature of the Jitter Gen environment.

The Lay of the Land

While the programming you do inside of any Gen object looks and feels like regular Max patching (connecting object boxes together with patch cords in ways that show you the flow of data), there are some important differences that are useful to know when you begin.

The Jitter Gen objects are no exception. They’re even a little different than the gen~ object you use for audio processing, in fact.

1. The things that happen inside of a Gen object are synchronous – there are no triggers and there’s no notion about the order in which things happen. In the Jitter world, the basic unit of data is a vector, which we’ll describe in greater detail in a minute. For now, think of this vector as a way to collectively describe a group of single pixels rather than a frame of video. Actually, it’s more correct to think of it as though you’re performing the same operation on every single individual pixel (unit of data) in the entire matrix at once.
2. To provide user input used for calculations and transformations inside a Jitter Gen object, we use the Gen param operator.
3. Most of the Jitter family of Gen objects only allow you to have a single outlet for your objects – you can have as many single matrix inputs as you’d like (each of which represents a single matrix), but only one output. The jit.gen object is the only exception to this rule.
4. There’s no way to retain the value of the pixel you’re working on from one operation to the next – if you’re familiar with the gen~ object, there’s no such thing as a history operator for Jitter Gen objects that you’d use for interpolation or filtering or delays (Don’t worry – there are ways to do what you’d use a history object for, which we’ll talk about in another tutorial).

Meet the family

The first thing you’ll notice about using Gen in the Jitter world is that there are three objects instead of one. Here’s how they differ:

The jit.pix and jit.gl.pix objects are made for standard Jitter 2d image processing. They work with input matrices with 1 to 4 planes, and treat incoming data like image data. The jit.gl.pix differs from the jit.pix object in that does all its work on the GPU (Graphics Processing Unit) instead of your CPU.

The jit.gen object is a general matrix processing object that works with any type of data that a matrix can contain (e.g. OpenGL).

In (both halves of) this tutorial, we’re going to be working with the jit.pix object.

Maps Make the Journey More Interesting

As we’ve said before, when you work with Jitter Gen objects, it’s easiest to think of it as performing the same operation on every single individual pixel (unit of data) in the entire matrix at once.

At a very low level, that’s how things like the jit.op or jit.expr objects work – a single operation is performed on each and every individual cell of the matrix or some part of the matrix, and the result of the calculations inside of your Jitter Gen object pops out the outlet of the object as a single matrix.

Let’s start with a really simple Jitter Gen patch. I’m a big fan of color mapping as a way to generate visual variety, so I’m going to start with a simple Gen patch that uses a cosine function to do some color remapping.

The inside of the jit.pix patch is much simpler than you might think from watching its output, but that’s because the relatively straightforward calculations on the inside of the patch are being applied to each and every pixel in the image (actually, the calculations are being performed on each and every pixel in the alpha, red, green, and blue planes).

Note: If you’re accustomed to only working with color in Jitter as char data in the range of 0 – 255, you might be wondering where the color processing is. Jitter actually has an additional way of specifying and working with color values – floating point values in the range of 0 – 1.0. In genland, colors are always specified using floating-point numbers.

Each input pixel is multiplied by an input value and then used as the input to a cosine function. Since we know that cosine functions output values in the range from -1.0 to 1.0, we’ll multiply the cosine function’s output by 0.5 and then add 0.5 to produce values in the 0. – 1.0 range that we expect for colors. The result is quick and easy color remapping – I particularly like the kind of results you get from using large values for the amp parameter.

Of course, we could replace the cos operator with any other kind of calculation we could think of (a sin operator would also work well, since its outputs fall into the same range as that of the cos operator), as long as we know in advance what the maximum and minimum values for the output range is so that we can coerce them into the 0. – 1.0 range.

In fact, the tutorial patch colormap_2a does precisely that. The patch not only adds the ability to pass the output unchanged, to select from either cosine or sine mappings, but also lets you choose to pass the data unchanged or invert its output for the passed or processed images. Here’s what the patch inside our jit.pix object looks like now:

Real-time waveform effects-chain processing

:: features ::

Drag-and-Drop audio files for rapid modification

Manipulate audio playback — dynamic looping, playback speed modulation, frequency modulation, forwards/reverse, dynamic pitch control

Loop-sync recording — automatically start and stop recording to a selected area — easily process loops and fragments

Re-record audio with real-time effects and playback manipulation (playback speed/direction, playback modulation and audio signal modulation)

Basic waveform editing — cropping, normalization

Easy MIDI mapping of controls and effects

Full suite of effects — delay, reverb, distortion, ring mod, and more

Recording — record as you play

Save/Load all effect settings

Audio Plugin Player is a lightweight VST and AU instrument plugin host for Mac OS X, that allows you to play these instruments using either your mouse, computer keyboard, or MIDI device (both hardware and software MIDI devices supported).  It has a simple, one-screen interface, that will let you start making music with your favorite audio instrument plugins in seconds – just choose your plugin, make your input and output choices, and you’re ready!

Additive harmonic sound design
:: features ::

Create unique sounds from scratch

Draw in a graph of up to 100 harmonics with graphic amplitude control for each

Precise harmonic design via numeric input

Resonator to dynamically apply pitch to sounds

Easy MIDI mapping of controls and effects

Full suite of effects — delay, reverb, distortion, ring mod, and more

Recording — record as you play

Download

free modular sound design suite for real-time performance

Flexible and in-depth frequency modulation synthesis

:: features ::

Frequency modulation synthesis

Two frequency modulation structures that can be cross modulated

Multiple modulation sources — static frequency, note frequency, Waveshaper, etc

Note input via QWERTY Keys and MIDI

Easy MIDI mapping of controls and effects

Full suite of effects — delay, reverb, distortion, ring mod, and more

Recording — record as you play

Save/Load all synth and effect settings

This is a model of Vassar College’s Electrocomp EML-200 that I built for my students.  Vassar’s EML-200 has a couple of hot-rodded features that the original didn’t have, such as the tuning knob for VCOs 1 and 2, and extra outputs for VCO 1 and 2, so I included those.   The EML-200 is quite limited in many respects: it has one AD envelope generator, its VCOs can only produce sawtooth waves, and it lacks a VCF.  Nevertheless, it can do quite a bit, particularly with creative routing (ring-mod = opportunity for envelope…), and I’ve included some presets.

Since we lacked a hardware sequencer, I built one based on the Moog 960.  It has almost of the features of the original–including the ability to be used as an oscillator itself–and I’ve added ways of randomizing/adjusting the values for the steps, and you can also use it as a full 24×3 step sequencer instead of an 8X3 or 24X1 step sequencer.  Click the numbered button at the bottom of a column in the step sequencer to temporarily activate that step.  As in the original, Row C can control the duration.

It also can record its output.  Specify the prefix (i.e. the beginning of the filename), and the path, and it will create filenames with timestamps in them so you don’t have to keep choosing new filenames.

Download

LICENSE:

Realtime effects processor for recording and performance

:: features ::

Audio input effects and recording — mics, guitars, keyboards — apply effects chains and record with luminous fluidity!

Audio input recording — in Windows, streaming audio recording is also possible

Real-time effects tweaking

Easy MIDI mapping of controls and effects

Full suite of effects — delay, reverb, distortion, ring mod, and more

Recording — record as you play

Save/Load all effect setting

Flexible realtime timestretching and pitchshifting with a granular engine in Max/MSP.

With this external you can expand your max toolkit for natural and experimental playback. It incorporates the algorithm used by Mattijs Kneppers in his granular stretcher patch and adds a load of extra options and features.

It is available for both windows and mac, and works in max 5 (in 32bit) and max 6 (in 64 bit).

The video below gives you an impression of what you can do with it by giving you a walkthrough using the helpfile:

Sequencomat (V1-V3) is a series of stepsequencers I made in Max for the Lemur.

I started in 2009 to create stepsequencer. First for the Jazzmutant Lemur, but now they also work with Liines Lemur App for iPad.
Between max and the Lemur control surface is a bidirectional OSC communication. All processing and Midi sending is done in max.

Sequencomat is based on classical stepsequencers with 8 track and 16 steps. As it is an ongoing development process, most features differ with the version: So while in V1 Midichannel, play direction, grid and steprange were global values (only changeable for all 8 tracks) in V3 these are trackvalues, independet for each track and saved within patterns. This allows e.g. polyrhytmic patterns and instrument jumping. And while V1 had only trackvalues for pitch, velocity and length in V3 these are stepvalues and also step propability, delay (to create a groove) and a ControlChange stepvalue was added. On full version you also got random switches for each stepvalue – making that special value variate within range.
One feature I like very much is a range object for the output of the stepvalues. So if you want to control e.g. veloctiy from 35-87 instead of 0-127 you can shrink the range and the faders will only output 35-87 (you still got the whole fader room, but the output is limited). In combination with that random switches in V3.3 you have something like “controlled random” (controlled in position and amount) which gives life to electronic music. But also you can create very detailed and concrete patterns.

Sequencomat V3 manual (incl. many screenshots)
Sequencomat V3_lite in the Liine User area
Sequencomat V3_lite in the Jazzmutant User area

Sequencomat V2 manual (last edit mid 2010)

Sequencomat V1 in the Jazzmutant User Area (last edit early 2010)

The tutorial which once get me into max, and on which Sequencomat was based – specially in V1 – are here:
http://www.jazzmutant.com/workshop_tutorialslist.php?id=maxstepA
http://www.jazzmutant.com/workshop_tutorialslist.php?id=maxstepB

Enjoy!
mat

QWERTY trigger-pad sampler with fluid audio manipulation

:: Features ::

Trigger-pad sampling with the QWERTY (alphabet) keyboard

Drag-and-Drop audio files for instant creativity

Instant control of samples — QWERTY keys are pre-mapped, ready to go

Trigger, gate and loop playback modes

Fluid Pitch Control — Pitch control of samples with infinite range and MIDI mapping

Instant forwards/reverse playback toggle

Visual waveform control — precisely define loop positions

Multiple step sequencers

Unique node sequencers — control sample looping off-the-grid

Node-based volume control — visual mixing of up to 26 channels

Easy MIDI mapping of controls and effects

Full suite of effects — delay, reverb, distortion, ring mod, and more

in-Built Recording

Save/Load all interface and effect settings

Four channel DJ Audio / Sound design performance with a 4-way crossfader

The Party Van is an ‘all-in-one’ performance patch built primarily around live sampling and improvisation.

It is built to be controlled by a Monome64, but everything functions with or without a Monome.

Features:

2 sample/loopers with overdub, halfspeed, and reverse functionality. Each with a sample slicer/dicer, granulator, pattern recorder, and MLR (monome app)  style buttons/display. Each looper can be put into ‘lofi’ mode to simulate the Where’s The Party At 8-bit sampler that inspired each module.

A series of realtime effects (stutter, pitch shift, lofi, filter, buffer shuffler, dirt, reverb, and chopper).

There is also a “reminder” row that circularly records all incoming audio and lets you play back any of it up to 10minutes in the past. (Great for real time sampling when you missed something awesome). (monome only)

There is no quantization. And all the modules play really nicely together. You can start recording a loop while in slicing mode, or switch between grain/normal and start where you left off, or record every knob wiggle in the pattern recorder, or reverse while creating your original loop etc…

As of V2 there is buffer analysis (using Alex Harker externals) that generates dynamic presets for the slice/grain modules based on what is recorded into the first two buffers. Each “brain” can be individually turned on/off, and you can morph between the current setting and the previous one.

The patch is an ongoing project/development with upcoming additions being real-time audio analysis to input/output effect parameter manipulation, real-time concatenative synthesis, a virtual ‘media’ player including glitchy/skipping CD, dusty/grungy record, wobbly/hissy tape, etc…

Create and perform textured beds of sound with rich layers of drone

Electronic Drum Synthesizer

Dynamically generate binaural tones

In part 1, Darwin showed us all the fundamentals behind step sequencing in Max, and extended that from the computer to the controller. With hands-on, real-time, improvisatory control over a sequence, he articulated the technical know-how to experience the joy of Max.

In this article, I’ll explore a step sequencer that accesses multiple sequences on different pages, geared towards drum programming, and provides a foundation for growth and room for curiosity.

When Darwin asked if I’d add to his series, I was already in the ecstatic throes of creating a Max for Live step sequencer (for a different Livid MIDI box, the CNTL:R), so it was a natural transition to adapt that device to work directly in Max and with the Code controller. I’ve been looking at the Code as a nice platform for a step sequencer ever since it came out, and this article was a good kick in my butt to get this project going.

• Download the Patches and Other Helpful Info
• Read Part One: Livid’s Code

Before I go into my motivations, technical details, and name-dropping of Max objects, let’s have some fun and see what this sequencer can do:

In the video, I take you through using the controller to access the four different sequences using the left-side buttons, controlling the sequences using the top 2 rows of encoders (and their buttons), and explaining how the bottom row of encoders work, each of which can act as a different control, depending on the toggle setting of the encoder’s button. The patch assumes you have the free and open-source TAL Noisemaker plugin (available for Windows and Mac).

Stick around to the end of the article where there’s another video featuring some different sounds from the Aalto plugin, demonstrates some of the other features, and suggests how to get more avant-garde results from the simplicity of a step sequencer.

This is a fairly ambitious patch, and you may experience some pain-on-the-brain. However, I’ve made a lot of comments and documentation available throughout the patch to help you understand the principles at work. I’ve also worked hard to avoid presentation mode in the Main patch, forcing it to be neat and explorable. Hopefully, if you read through this article, and maybe try altering some of the assignments to see what happens, you’ll become comfortable with making this instrument your own.

Considerations for Controllers with LEDs

It’s easy to get carried away with “possibility” and “potential” with all these buttons and knobs on the Code. Before I start hooking up MIDI to my patch, I need to wrangle all these options into sensible, meaningful ways that don’t require a lot of patching.

As a Max user, you’ve probably noticed from the sheer array of button options (textbutton, live.button, button, live.toggle, toggle, pictctl, matrixctl, radiogroup, tab,…did I miss any?), so the term “button” is a loaded one.

There’s several modes for this button thing: momentary, toggle, and radio, and they all require their own considerations when patching. The Code itself is a pretty “dumb” controller – it’s designed to work with a computer, so it leaves all the hard decisions to the host software, rather than trying to accommodate several different types of button logics in its internal firmware and limited onboard memory. That means when programming in Max, we have some work to do!

Similarly, the encoders add a bit of a kink to what might seem a simple task of sending some MIDI cc’s and hooking them up to a UI object. Because we now have four sequences to work with, we want the encoders LED rings to update their displays so they relate to the data in the sequence we just chose. This means when you select a sequence, you want to have all the current values handy to send to the controller instantly so you can keep making music.

For the more casual user of Max, this type of stuff can be a bit overwhelming. Max lends itself to rapid programming, and quickly realizing ideas that come from the thing you just built. This is what makes it fun, but when it comes to “clerical work,” like making sure your controller is updated with all the right values, you can sometimes patch yourself into a knot.

Because I deal with a lot of different controllers (I see seven in front of me right now!), I’ve had to constantly refine my practices to accommodate new controllers, not only from Livid, but from other manufacturers as well. As such, I want to make things flexible enough to take different, arbitrary midi messages in, scale the 0-127 in to whatever I need, control my patch, and take UI data from my patch and be able to translate it back to MIDI so I can send it to update the controller. I also want to be able to redefine these assignments on the fly. The current state of this art is mostly encapsulated in the js midi2mess.js.

As a result of all this work and a centralized communication system, people who have other controllers not named Livid Code (but, hopefully with the word “Livid” on it!) can adapt this patch to their own controllers without ever having to touch a patch cord.

The Big Picture: MIDI in, Message out. Message in, MIDI out.

If I press a button on the Code, this button might need to go to somewhere in the main patch, in a subpatch, or even in a subpatch-in-the-subpatch.
And when I press it, I want the UI on the screen to update.

Similarly, when I press a button the screen (which might live in the main patch, or in a subpatch, I want to know that it happened, and tell my controller that this button has changed.

Many patches often handle this type of inter-patch communication with the send and receive objects. However, pattrstorage provides a much neater, consistent, flexible, and elegant way to deal with all of this data.

As a result, I tend to avoid send and receive as much as possible, and use pattr to provide hooks to pattrstorage. My relationship with send and receive is not unlike my relationship with pets: I have lived with pets, and enjoyed them, however, now that I do not live with a pet, I do not miss cleaning up after them, and I like having an untorn sofa! Take a look in the patch “About pattrstorage” to read more about how I use pattrstorage to communicate in my patch.

I use javascript (midi2mess.js) to handle the MIDI data. While this may have some cost in speed, it creates a very flexible system that integrates in a nice cycle of life with pattrstorage.

Metaphorically, it’s like the rain and the earth: pattrstorage rains data on the land of my javascript. The data evaporates on the javascript and floats back up to the pattrstorage, where it rains again. Except it all happens instantly and precisely, no flooding occurs, the streets are still safe to drive on, leaving writers safe and dry to stretch their metaphors to unpoetic lengths.

If this system is confusing to you, or you want a “safer” place to wrap your head around it, take a look at this patch.