Working with Hardware: Livid’s Code (Part Two)

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.

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.

Working with Hardware: Livid’s Code (Part Two)

Feb 9, 2012 at 2:51am

Great article indeed!! I’ve been trying myself to build in Logic a sequencer in the environment page. Turns out to be a lot more complicated then expected :/ Do you mind me asking if u have any experience in integrating CODE with Logic?

Feb 9, 2012 at 7:41am

I dont’ have any experience with Logic. I can’t imagine it would be an easy task, though. I do have a simpler, stripped down version of this beast that does away with the “timbre” steps and the vsts. This instead sends MIDI out to a chosen MIDI port on each sequence. Theres likely some adjustments that need to be done to the messages that setup “js midi2mess.js” because some things are still assigned to the “timbre” stuff.

Feb 9, 2012 at 9:15am

I’ve gonna order one in the next days & give it a try!! I have no knowledge regarding MAX/MSP, but i find it so fascinating. Must be the geek in me that is drown to these kind of things :)


You must be logged in to reply to this topic.