fuse*

Multiverse is an audio-visual installation that draws inspiration from these concepts and, through the creation of a sequence of digital paintings, generated in real-time, attempts to represent the eternal birth and death of infinite parallel universes. The concept of eternity and the idea of infinity are translated also with the modality in which the visitor and the artwork interact with each other.

The installation consists of a vertical projection of 7.5 meters high and two large mirroring surfaces that generate an infinite reflection of the image towards the sky and the center of the earth. The goal is to increase the perception of reality by giving the impression that the installation is going beyond the physical walls projecting itself into a boundless space. Realising this artwork inside a deconsecrated church for the first time assumes consequently a very important symbolic meaning.

Multiverse is an audio-visual installation that draws inspiration from these concepts and, through the creation of a sequence of digital pai

multiverse

Multiverse

Matthew Davidson

The Livid Code is designed to be useable out of the box without programming. The default behavior of the Code's 32 encoders is to send values in the range of 0 to 127 as MIDI continuous controller (CC) messages. These messages can be easily assigned to software synthesizers to control parameters, providing a physical knob to any virtual instrument that supports controller mapping. The firmware of the Code produces an indication of the value on the LED ring that encircles each encoder.

This behavior, while handy, doesn't leverage the endless resolution of rotary encoders. The same thing could be accomplished with normal potentiometers without LED rings. If you want to unlock the true potential of the Code, you need to decouple the LED rings from the encoders. This tutorial will show you how to do this in Max, without resorting to JavaScript. Effectively, we'll get Max's interface to the Code down to a simple number box, and if you can manipulate a number box in Max, you can do some amazing things with the Code.

The first thing we need to do is set the Code to a known state. The best way to do that is to reset it to its factory default settings. All communication with the Code is accomplished via MIDI messages. The knobs and buttons on the Code send MIDI continuous controller or note messages. Messages that change change the behavior of the Code need to be a bit more flexible, so this is accomplished with system exclusive messages. The admittedly awesome Livid Code wiki details all the messages the Code responds to. Included in this tutorial are examples of these messages, formatted as working Max patches that you can easily adapt to your own use.

Even though the Code uses MIDI to communicate, you don't need to hook up the MIDI ports on the unit itself. All you need to connect is a single USB cable which both provides power and transports the data. No drivers are required to install.

The first patch example establishes the MIDI port on which the Code communicates. Click on the sysex string to reset the code. The ctlin object instantly responds to the values sent from the Code's encoders.

Now that the Code is in a known state, let's decouple the LED rings from the encoders. Currently, the internal firmware of the Code is controlling the LEDs, but we want to do this from Max. This is like turning local control off on a MIDI synthesizer, which decouples the sound engine from the keyboard, so the routing can be controlled with a computer.

Click on the sysex message in patch example 2 to tell the Code you want to change its behavior. Don't worry, you can always revert to the factory defaults with one click. Once you've done that, you'll notice the LEDs do not respond when you turn an encoder. This is what we want. Values are still sent out from the encoders, but if the LEDs are going to do anything, we're going to have to explicitly tell them to do so from Max.

128 steps of resolution is suitable for a lot of tasks, but with rotary encoders, we have the ability to precisely tailor the value range. We want the encoders to tell us when they are incremented or decremented. Another sysex message puts the Code into 'delta mode'  Now the Code sends a '1' on increment and a '127' on decrement. This may seem like a step backwards, but now the encoders are unbounded. In other words, they don't stop sending values when they reach 0 or 127. We can keep them unbounded or set the bounds ourselves to whatever we want.

We've built our own accumulator using the accum object to keep track of the increments and decrements as a running value. This produces an unbounded number that is edited with the first encoder on the Code.

Now let's put the LEDs under the control of Max. The state of each encoder ring is set with a two byte message. The first byte sets the left half of the LED ring, the second sets the right half.

Open the individual_LEDs subpatcher. You'll see a series of check boxes that correspond to each LED on encoder 1. Each LED is a bit representing its on/off state. The cumulative state of the left seven LEDs are packed together to fit inside a single byte. The same thing happens on the right side, albeit, the center LED is already represented in the first byte. Thus, any combination of the 13 LEDs can be represented with two numbers between 0 to 127. The frombin subpatcher formats the bits into the appropriate number.

Back to the main patch, I've sequenced useful combinations of LED states into reusable primitives, like 'level' (rising cumulative clockwise values), 'indicator' ('interpolated' neighboring LEDs for more display resolution, like the default firmware mode) and pan (for bi-polar values). The coll objects contain two numbers (representing the two sides of the LED ring) and associates them to a simple index. This allows you to forget all this bit byte stuff and easily change the LED behavior of an encoder ring by using the data in one of these coll objects. You can easily create your own behaviors by designing patterns using the individual_LEDs subpatcher.

The format subpatcher takes the resulting two bytes and formats the rest of the sysex message to update the LED ring. Inside the subpatcher, you'll notice a pak with 64 inputs. There are 32 encoders, each with two 'sides'. The entire resulting sysex message encompasses all 32 encoders, so if you want to update the state of one encoder, you have to update all 32 of them. The upside is this is fairly efficient and the entire surface of the code (416 LEDs) can be safely/smoothly updated every 2ms or so.The pak object is good if the LEDs are directly driven from the encoder input, but if something else is driving the LED refresh, it is better to use a pack (or a join with one trigger input) and poll the first input at a regular rate.

Now let's connect the output of the encoder to the LEDs. Under 'initialize code' we have the full initialization sequence that resets the code, decouples the LEDs and sets the encoders to delta mode.

The accumulator last seen in patch 3 is now encapsulated in a subpatcher called 'accumulator'.  We've arbitrarily decided on a bounded bi-polar resolution of 301 steps from -150 to 150. Additionally, we've pattr-enabled the accum object itself so we can remember and recall its value.

The output of the accumulator can be seen in the large message display labeled 'value' in the patch. We don't have 301 LEDs, so we need to scale this value down to our 13 LEDs per encoder. This gets sent into the pan-behavior coll seen in patcher 4 to represent a bi-polar value.

The pattr preset section demonstrates the value of placing the LEDs under software control. We can recall presets and even interpolate between them.

The example patch takes everything we've learned in the previous patches and applies it to the entire code surface. This patch assembles three different encoder behaviors (volume, pan and indicator) into a typical mixer-type arrangement of eight 'channels' of four attributes.

The 'code ring' subpatcher formats the entire LED surface of the code into a single sysex message. The behavior and resolution of each individual encoder is assembled from some easily-modified, pre-built abstractions. The argument on each abstraction serves as an address for each encoder.

This demonstrates complete software control over the Code with Max and allows you to easily build code surfaces with different encoder resolutions, bounds and LED behaviors.

A synthesizer, or any music-technology product for that matter, can't be all things to all people. Max allows the creation of useful tools that are extremely specialized. It is fun to look at a control surface like the Code and design a music application from the interface down. When I looked at the 32 encoders of the Code, I immediately thought of additive synthesis. Additive offers distinctively beautiful clear tones, but is often ignored because programming partials is kind of dull. The Code offers some potentially fun and powerful ways to apply tactile surface to additive.

Harmonic Designer, included in the applications folder of this tutorial download package, is a 32-harmonic additive waveform designer. Harmonic Designer is a companion application for Wavestep and Drone Designer. Harrmonic Designer builds the wavetables that these applications use. The amplitude of each harmonic, starting with the fundamental and moving up the harmonic series, is programmed with the 32 encoders of the code. Press an encoder knob to zero the amplitude of that harmonic. Zero all the amplitudes, with the 'zero all' button. Waveforms are stored into slots of the preset object with a shift click. Collections of waveform presets are written to a json file (harmonics.json) which is read as a wavetable by the Wavestep and Drone Designer applications. Write the harmonics.json file into the wavestep and/or drone designer folders. The next time they launch, they'll use the new waves.

An accumulator abstraction, "ind", takes two arguments.

The Code's four rows of eight encoders output continuous controllers sequentially from 1 to 32. However, the humber follows a top to bottom order. In other words, the top left encoder is 1, the next encoder DOWN is 2. I tend to think of a string of 32 harmonics as progressing horizontally, so the accumulator abstraction for harmonic designer, "ind.maxpat" takes two arguments. The first argument specifies which hardware encoder (1-32). The second argument specifies the data order. So, the argument of 'ind 5 2' specifies the next encoder to to the RIGHT of the first encoder (5) is the (2) second harmonic.

Drone Designer is a four-voice wave interpolation synthesizer built specifically for drones. Drone Designer plays back waves created with Harmonic Designer. Two waves are specified as an 'A' wave and a 'B' wave.  Interpolating between these waves creates smooth timbral shifts. The resulting continuously morphing wave is then sent to a tremolo effect. Exploring the interplay of these two modulations is where the fun is at. Then you can start layering voices.

Each voice has eight parameters. Each row of encoders on the Code represents one 'voice'. Drone Designer plays back the waves created in Harmonic Designer.

column one: tremolo rate
column two: wave interpolation rate
column three: pitch
column four: wave a
column five: wave b
column six: volume
column seven: pan
column eight: effects send

The four row buttons mute/unmute individual voices.

All the encoders in Harmonic Designer behave the same way. So, they all share the same encoder abstraction. Drone Designer uses encoders of varying resolution, so each class of encoder behavior shares its own, unique abstraction. For example, the pitch encoder has a range from 12 to 80 but the LFO rate encoders use a range from 0-150.

The two wave encoders differ subtly as they each access a different wave location. Otherwise, they're identical.

The dd_voice abstraction collects the encoder inputs for each voice and produces the sound.

There are eight parameters within dd_voice. The eight arguments on designate which encoders are used. For example, the argument: 1 5 9 13 17 21 25 29 specifies the top row of encoders on the Code.

The LEDs still have to be rendered so the outlets of  dd_voice feed the code_ring subpatcher that formats the huge sysex message that updates every LED ring on the Code. The LFOs that govern the tremolo and wave morphing effect display the phase of the LFO output. so the entire LED surface of the code is updated every few milliseconds. This is a good example of a totally decoupled encoder/led action. A graphic representation of the LFO rate provides more feedback than an arbitrary indicator bar.

Wavestep is an additive synthesis sequencer instrument. The sequencer controls both pitch and relevant synthesis parameters, such as which wave used. There are 32 steps to program. The eight buttons across the bottom of the code select which parameter is edited. Each encoder on the code represents one of the 32 steps of parameters on that page.

Previous examples of uncoupled code operation involve formatting the data from the code's encoders into messages that control the behavior of the LED rings. Wavestep also formats the data into strings that write structured data into a dict object.

The sequence output is constructed from reading the structured data back from the file.

Describing all the dict bits is beyond the scope of this working with hardware tutorial, but if you're looking for an example of interfacing a control surface with dict, this application may offer some insight.

There is no edit buffer, so there is no need for a save button. Be aware that any editing you do is written immediately into the current preset. If you want to start from scratch, select an unused preset and start from there, or use the randomize preset.maxpat concurrently with wavestep after you have selected a preset. The randomizer will write directly into the current preset. If you wish to set every step to the same value, use a very small range on the range slider.

The order of the eight edit pages, as accessed on the Code are:

pitch (base pitch of step) (pressing encoder button enables/disables step)

wave (wave selection) (pressing encoder button enables/disables wave interpolation)

gate time delta (gate time is determined by the step duration parameter. this parameter modulates the gate time)

attack time delta (this parameter modules the attack time of the envelope)

decay time delta (this parameter modules the decay time of the envelope)

sustain time delta (this parameter modules the sustain level of the envelope)

release time delta (this parameter modules the release time of the envelope)

step duration (*determines the duration of the step in tempo relative units from 128n to 1nd)

* this parameter is ignored if pulse selection is set to fixed. In that case, the pulse is determined by the fixed pulse menu

That concludes the third and final part of our first Working With Hardware feature on the Livid Code. Although the examples are specific to the that surface, the techniques we explored can be applied to any hardware interface.


hardware: Livid Code
software: harmonic designer, drone designer and wavestep

download this software at http://cycling74.com

This is the companion video to Working With Hardware part three. In addition to a tutorial on how to build your own Max applications that use the Live Code, four free applications are included. These applications are demoed in this video. 

http://cycling74.com/2012/01/04/working-with-hardware-livid-instruments%E2%80...

Drone Designer hosts audio effects plug ins, the sends of which are controlled from the Code. An Audio Damage Eos reverb was used on both the Drone Designer and wavestep examples. A tempo synced delay is included in wavestep.

Livid Code applications demo Max 6

Part 3 of the tutorial series on Livid Instruments' Code.

working-with-hardware-livid’s-code-part-three

Working with Hardware: Livid’s Code

Gregory Taylor

After doing a quick tutorial at the Cycling ’74 Expo, it became clear that lots of people out there were really surprised and happy to discover that they didn’t need to be a supergenius to have fun with the gen~ object. While the new Gen stuff is as elegant and powerful as the day is long, you can also have quite a lot of enjoyment with a very few objects. So here’s a sequence of little patches that I hope will give you a window into having some audio fun without scaring the bejeepers out of you. These patches are not impossibly complicated, or efficient or elegant – they’re the product of someone at play. I hope they encourage you to play, too. I even added some simple presets to spur your imagination.

All tutorials in this series: Part 1, gen~: The Garden of Earthly Delays, Part 2a: The Joy of Swiz, Part 2b: Adventures in Vectorland 

Gen need not be Rocket Surgery (although the Rocket Surgeons will find much to enjoy, I’m sure), but there are a few simple things that it’ll help to know when looking at these patches.

 The flow of data inside the gen~ object  is like MSP in that it’s synchronous, but instead of thinking of performing some action on a block of samples, we’re working with one sample at a time - which lets us do things with single-sample feedback that we could never do before.

 The flow of data inside the gen~ object  is constant – there isn’t anything like a trigger, for example. It also means that gen~ operators are always sending something out – a signal sample value, a parameter value, or the result of a test of some kind. We need something special that lets us control our patch with messages from the “outside world.” In the Gen world, we have the param (parameter) operator to do that. You’ll see it in use here.

 Since data is always synchronous, a feedback loop isn’t really possible. Instead, we have an operator called history that acts like a single-sample delay that lets us create feedback loops for useful things like data smoothing and… well… feedback.

 One difference you may notice between Gen objects and their Max cousins has to do with the relationship between arguments to a Gen operator and the number of inlets the operator has. Unlike Max object, using arguments to specify an initial value for a Gen operator changes the number of inlets an object has – that’s because those initial values cannot be changed once specified. Here’s a simple example of that relationship using the mixer object, which we’ll be making good use of in just a minute.

This tutorial is going to be about manipulating delay lines. Since the gen~ object gives us access to audio on a per-sample basis – and thus lets us set feedback loops that are tighter than the signal-vector variety that MSP provides, there’s a lot of room for creating new sounds.

The first patch drive-by1a.maxpat, demonstrates a few simple features of working with delays (using the delay operator):

Like the MSP tapin~ object, the delay operator at the heart of this patch takes an argument that specifies the length of the maximum delay possible (remember that since we’re working with gen~, that amount is specified in samples). Although the delay operator can take a second argument to set multiple taps, we’ll only need one delay line each for the left and right channels of our stereo gen~ patch. You might want to investigate that for yourself later on.

The other crucial piece of our patch is the mix operator. It not only lets us mix the wet and dry signals for output, but it introduces a way of smoothing data that gen~ aficionados use everywhere. The mix operator takes two input values in the first two inputs, and then outputs an interpolated value based on a value between 0. and 1.0 received in the right inlet. And of course, it works on one sample at a time.

You’ll see the mix operator used in two places – to handle the wet/dry mix of the delayed and non-delayed signals (notice the clip -1 1 operator for waveform hygiene), and to create a mixable delay line. In both cases, we’ve added a param operator that allows us to send messages to the gen~ object to set values by means of messages to our gen~ object. Of course, we could have adding another in operator or two and used the MSP sig~ object to control our patch - you might find that technique more to your liking, in fact.

The wet-dry mix should be pretty straight ahead, but I want to take a minute to consider this generalized example of using the mix operator for feedback and data smoothing. Here's a generalized example of how to add feedback effects:

The feedback portion of the patch also uses the mix operator along with a param operator to control the balance of the current and previous signal values. Since the Gen environment is synchronous, we can’t connect the output of the mix operator directly to one of its inputs to create a feedback loop. But don’t worry – the Gen history fb 0. operator functions as a single-sample delay line and will allow us to add the mixed signal back to itself (typing an argument into the history operator also lets us specify a starting value of zero for our feedback loop). If you have a specific kind of data smoothing in mind that doesn't require modication of the amount of the previous signal being mixed in, you can add an argument to the mix object (e.g. mix 0.5) and skip the param object entirely. The clever trainspotter reading this tutorial is probably already thinking, "Hmm. Isn't that a kind of lowpass filter?"

Yes, it is. And if you spend some quality time in the Gen examples folder, you'll see some variation of it used quite often.

In the case of our example patch, we're using this feedback loop twice in the patch - once for the left and right channels. In the case of our example patch, we send the averaged sample values on as output to the wet/dry mix, and also re-inject them into our delay operator. The result is the classic ringing delay line with a damping control. You can use this particular kind of patch for all kinds of useful tasks.

Note: the fold -1 1 operator makes sure that the feedback values never increase above a value of 1.0 or below a value of -1.0 – if they do, they’ll be folded back for the next iteration. It’s a simple way of producing self-regulated output.

Try the patch with a variety of different kinds of input audio files – some things will sound interesting, some won’t (that’s because an algorithm is never an automatic guarantee of interesting output unless you’re a hard-core formalist).

Often, you don’t really need to do anything really difficult to get good results. Our second patch drive-by1b.maxpat builds on that with a few simple extensions. Since one damped ringing delay line sounded pretty wonderful, let’s add another one for each channel (and an MSP line~ object in the patch to smooth things out a little on input), and let’s also add another of those mixer-history-feedback modules to the overall output to add some ringing to the combined signals. I’ll wager that the resulting howling and humming will get you thinking about the same thing as I did – I started using mathematically related input values for the number of samples to delay to get tuned or harmonic effects. Please feel free to live with the harshly soothing sound of this patch for a while.

drive-by1c.maxpat, the third iteration of our patch, does its work outside of the gen~ object itself – it adds a simple little subpatcher named that lets us tune the ringing delay lines by using a keyboard – I’m sure it’s occurred to you that this would be handy to do (although I found tuning the delay lines by hand to be a pleasant and restful activity). Here’s the inside of the subpatcher for your study and edification.

I’m sure that some of you may already be thinking about just intervals (musical intervals that can be expressed as simple whole-number frequency ratios) rather than living with the equally tempered intervals that the Max mtof object produces. Feel free to make those changes for yourself (they sound pretty wonderful, trust me).

drive-by1d.maxpat, the fourth iteration of our drive-by tutorial patch, adds a final minor variation that manages a modestly impressive major transformation of the proceedings.

All we've added is a gate operator, which functions in much the same way as its Max and MSP cousins - an incoming message relayed by way of the param operator named feeder is used to send the delayed signal for reinjection into the delay line to one of the four delay lines we've set up. That means you can route your signal back to itself (as we've done all along), to the second tuned delay line on the same audio channel, or to the first or second delay lines on the opposite channel. The result of this reassignment is that the ringing delays become quite complex - the interplay of damping and pitch and the routing of the delayed signals result in some really interesting sounds.

Of course, there are always other possibilities. More ringing delay lines? Sure. More complex routing? You betcha. More subtle approaches to amplitude control? Why not? This is a shameless attempt (as is the omission of the wet/dry mixer logic in the last couple of examples, to be honest) to encourage you to play around with the patch. Good luck and happy patching!


Sequence of little patches for some audio fun.

gen-tutorial-1-the-garden-of-earthly-delays

gen~: The Garden of Earthly Delays

Peter Nyboer

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

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.

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.

I've structured this patch so that it's not too complicated in its structure.

 There is some patching to find the Code controller automatically and provide midi input and midi output.

A pattrstorage object in the main patch that provides links to all the parameters in the patch and its subpatches, as well as an output of all the message changes in the patch that can be fed into the...

Javascript "midi2mess.js" takes midi input and matches it up with the "pattrstorage paths" that we've defined with the "latch" message. This is fully documented in the patch itself, so I won't waste valuable blog space boring you with that! Suffice to say, it translates MIDI into a message that pattrstorage distributes to the right place.

A patch that creates "latch" messages for the javascript to link MIDI commands to various parameters.

There is a simple abstraction, used four times, to host VSTs, one for each sequence.

There is another small abstraction to host timbre effects for the resonating bank of filters and the lowpass filter.

The four sequences are in bpatchers that output notes for the synth plugins and control data for the timbre effects. These are moved around by some simple scripting commands for thispatcher, so your chosen sequence is always at top.

I won't go into the level of detail that Darwin did - he covers most of what is important in creating a stepping system, and I use most of the lessons to create a more feature-rich system. Again, I'll speak more to my goals and some of the challenges these present, and how I worked those problems into something manageable.

Because this project is branched from a Max For Live device, I use a lot of the UI objects that come with Max for Live. While these provide a bit of a different look than regular Max UI objects, the main reason to use them is that their built-in "parameter mode" provides links in to Live's state retrieval system. This made it easier to design something robust that makes it work "as expected" in Live, so the sequencer returns to the way you left it after you saved a set. It also provides a more capable user interface that I would have cared to build from scratch: the live.step provides multiple layers of editing, easy note editing, and sliders and colors to provide nice on-screen feedback from using the Code.  Because live.step has a helpfile, I won't go into the details.

However, I had to make some adjustments to get the live.step working in my system of pattrstorage-based messaging, as well as create step "enable/disable" toggles that provide added visual feedback in the live.step UI that a step is "off."

The bulk of this work is handled in the subpatcher "p steps" and the array of 16 live.toggle buttons, paired with pattr objects. This paring of pattr+live.toggle give me messaging connections to and preset storage for pattrstorage. Because live.step uses lists to communicate, I need to break up those lists into their individual components so I can use individual controls on the Code to talk to them. This required a decent amount of objects and connections, but you'll notice that this was mostly scripted into existence, and neatly contained in a subpatch.

While this patch presents a fun and playable instrument, I definitely leave a lot of room for growth and user-decisions. Here's a video that shows of some of the other features in the sequencer that could be mapped to the controls of the Code or are good for programmatic control:

In the video, I use the "chance" elements to create random variation, loaded a different plugin (Aalto from Madrona Labs) and made a really simple "LFO" to modify the tempo. The result is vastly more avant-garde than the first video, and can help you shore up your academic street-cred.

Here are a few ideas that I have for modification:

The VST and "timbre" areas are ripe for refinements. In fact, if you have a favorite VST, it would be a worthwhile project to scrap my "timbre" effects and tie the controller directly into the parameters of the plug-in through the vst~ object using the filters, envelopes, and effects that might exist in the plug-in. This would mean you'd have to create some new midi+message definitions, create some new pattr objects in the "ez-vst.maxpat" abstraction, and change the messages sent from the cellblock in the "stepseq.maxpat". Check the vst~ and the "ez-vst" helpfile to see how to send messages to change the parameters in a plugin from your Max patch.

There are also some notes on how to create a momentary "shift" button that will reassign parts of the controller to completely different parameters in the patch. This type of thing is pure gold when working with the finite realm of a controller and the infinite world of software, since you can expand your controller with different pages and modes without adding more hardware.

The Clock subpatch in the "stepseq.maxpat" also has a highlighted area of a project worth finishing up by a curious user. This has some hints on how to create a "fill" sequence - a different sequence that would play every "n" measures that would be different from your main sequence. This would provide some really cool variations in a sequence.

Expand from four to eight (or even 16!) sequences, and move the sequence selectors to the bottom row of buttons. This would entail duplicating the bpatchers, making sure they have the correct scripting name and arguments, and re-defining some of the midi & message assignments.

Because everything is designed around pattrstorage, you can experiment with creating patterns (and using the code to fire those patterns off), and even using the nodes object to interface with pattrstorage for some radical interpolation.

Finally, there's no reason the step interface needs to be so small. Make it bigger so you can put your computer farther away!

I hope this writeup and patch are clear enough for you to dig in and modify. But before you do, spend some time just PLAYING with it and make some music. Feel free to contact me with any questions.

This step sequencer written in Cycling '74s Max6 for the Livid Code MIDI controller is made for quick, interactive fun. This shows how to use the encoders, encoder buttons, and buttons to control the sequencer. I've left some buttons open and added a lot of documnetation so you can experiment with the Max patch and make it fit your own style. The patch assumes you have the free-and-open-source VST plugin "TAL Noisemaker" http://kunz.corrupt.ch/products/tal-noisemaker

Code Step Overview

Using the Aalto synth from Madrona Labs to accentuate the weirdness, I demonstrate some of the features in in my Max 6 step sequencer that are available for mapping to hardware. With a couple of tweaks and some different sounds, we can move from "minimal techno" to "contemporary algorithmic." This was used for a complete article about sequencing and the Code at cycling74's website:<br />
http://cycling74.com/2012/01/17/working-with-hardware-livids-code-part-two/

Code Step in Max6: More features.

working-with-hardware-livids-code-part-two

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

Darwin Grosse

Welcome to the first installment of a new series: “Working With Hardware”. For our first go-around, we are going to be working with a relatively new hardware controller – the Livid Instruments' Code – and will create some useful software for this system from scratch. I’m going to start by making a basic sequencer, and then we will follow up with a few more advanced tutorials, giving you the opportunity to follow several developers as they create useful and interesting software for a specific device.

After taking a quick look at the Code, I realized that all the pieces were there for an interesting sequencing device. We have multiple rows of knobs, row and column buttons, and a nice big button that would be perfect for a start/stop button. Something you might not be able to tell from product pictures, though, is a key feature: each of the rotary encoders is also a push-button switch, something I could use for individual step gating as well. That was all that I needed to know to get started.

The Livid website has a pointer to a Wiki page that had a lot of great information. The most useful part of the documentation was the following diagram:

Since the Livid Code is a MIDI device, this one diagram held all the keys to the kingdom for me. Using this documentation and a piece of scratch paper, I started putting together my plans for a super 32-step sequencing device, where the entire user interface would be done at the controller.

The first thing that I wanted to tackle was the clocking system – the core of any step sequencer, and a challenge for a hardware-centric UI. While each step has a small white LED available, I wanted to leave those for individual step gating, so I had to find something else.

With a set of row and column buttons, I realized that I could just show the current step by showing the current row and column; visually, it would be easy to track the step by triangulating the two points. Since I was going to make this a full-on 32-step sequencer, it meant that I needed to get something that would count from 1 to 32 (or better yet, 0 to 31), then map that to the buttons.
I started with the basis for any good timing system: the transport object. I decided to stick with 16th notes, so I just built a simple way to start and stop the transport, and I used a few simple math objects to get the output down to a 0-31 range. Once I had that range, I further split the numbers so that I had a row (0-3) and column (0-7) number that could map to the Code’s buttons.

Now that I had a tracking system, I needed to tie it to the physical device. Working with MIDI for this is a breeze, so I just started with a basic midiin and midiout scheme (with midiparse and midiformat, respectively) and a few objects to let me select a MIDI device. Creating the start/stop button was first: since buttons map to MIDI notes, and the Big Button is mapped to MIDI Note 37, I just took the incoming note stream, checked for 37, and toggled the transport on and off on each push. You’ll also note that I reset the transport time to 0 (the beginning) whenever I stop.

Next up is the display of the current row and column. We are going to use the numbers that we got from our clocking system and generate notes from them: a note sent to a particular button will turn on the built-in LED, while a note-off will turn it off. Rather than do a bunch of calculations to determine how long the LED should stay on, we’ll just use the makenote object’s ability to slave to the transport, and have it control its own duration.

We take the column number and add 38 to it – this will work with the buttons from left to right. Since we are clocking the system at 16th notes, having the button’s LED strobe at 32nd notes seems appropriate. So that’s what we do – and we now have the columns displaying the current step.

The rows are handled similarly, only starting with MIDI note 33. Using similar logic (but instead using 16th notes, so the row stays on for the duration of the steps), we can get row displays happening. Once this is in place (and saved, please…), we have a clocking system that is easy to program – and easy to see.

Select the Code as the incoming MIDI device (the menu at the top).

Select the Code as the outgoing MIDI device (the menu at the bottom).

Click the bottom-left button on the code, and you should see the system running, rows top-to-bottom, columns left-to-right.

Next up is using the rotary encoders to retrieve and generate notes – the point of the next section. But in order to keep our patch tidy, let’s encapsulate most of the existing code in a subpatcher. I’m going to have an inlet and an outlet for the MIDI input and output (since we will want to share this data with other subsystems), and also have the tempo input and current step output exposed to the outside world. I select everything else, choose the “Encapsulate” option from the Edit menu, and I have a super-clean interface as I start my next bit of programming.

The rotary encoders of the Code are exposed as MIDI CC messages, with the controller representing the encoder number, and the value as the CC value. This is quite easy to parse into a row/column combination using the following code:

The easiest way to deal with the storage of the four rows of data is within four multislider objects. In addition to maintaining the state, it is rather easy to pull individual data segments out, and we get a nice little display for debugging purposes. Using a route object to choose the row, we then prepend the select message to the data so that only a single slider is updated. Now, if we move the rotary encoders, we should see the multislider object change their values in concert with our movements.

One thing to note: we had to add a one (1) to the column number, since the multislider column count begins at 1, not 0. This is a small price to pay for all the functionality that we get, so we can live with it!

Now, to get the data out again, we have to “ping” the correct multislider to get a column value. Given the output of our timing system, we have the current row and column. This gives us the data we need to route to the right multislider, then use the fetch message to grab a single column’s value. Again, we have to add 1 to the column count because of how the multislider works.

Now, we have data – the current step’s value – available as an output. There are many ways you could deal with this output; in my case, I choose to limit it to the range of 48 through 72, and to run it through a little abstraction that will force it to be in a minor pentatonic scale. From here I route it into a separate makenote object (one dedicated to the note output), and I can play my sequence right off.

If you wanted to make the note player more robust, you could use more complex programming for the output scaling, or you could build a secondary grid system for note selection. In this case, though, I just wanted a sequencer that would work simply and musically, so I went down the path that I did. To tidy up the patch before I begin the next section, I again encapsulate everything specific to the note generation and end up with a tight little patch:

What we have now is a pretty credible step sequencer – 64 notes that play based off of a 4x8 grid of rotary controls, and all coerced into a nice little pentatonic scale. But there are two parts of the hardware that we can use to make it even more interesting: the per-step LED, and the push-button switch built into the rotary controller. What we will do is to use the switch to set the gate for each step, allowing us to make more interesting phrases from our step sequences.

The switches are MIDI note producers, using the note numbers that match the rotary controller numbers. The LEDs are note-receivers, following the same note number map. So grabbing the incoming note information (and sending note information) will allow us to manage the entire gating grid.

The output of the switches is [note number, velocity], where the velocity is 64 if pushed down, and 0 if released. Since we don’t want to have to hold down an encoder to hear a step, we need to change this functionality into a toggle-like output. Probably the easiest way to do this is to literally use a toggle object, looking for a velocity of 64 as an indication of a switch press. We also need to turn the LED on or off based on the toggle value. Thus, we make a little fixture that we can use for each row’s grid system.

Now, if we use four of these fixtures for the four rows of the Code, we have a grid system ready to go. We need to connect it to the clocking system we created earlier, and we should be able to get gates out as the sequencer steps through the 64 stages. The last thing we need to do is to route the output to the MIDI note producer, so that only steps with their gates on will be output.

Finally, we wrap this up into another encapsulation (subpatcher), add a few comments, and we have a top-level patch that is simple and ready to use:

Again, there are many ways that you could expand this sequencer: you could add a preset system, you could find a way to control the tempo with the hardware, or you could build in a system to select specific steps during performance.In our next article, we are going to turn to Peter Nyboer, the chief programmer at Livid Instruments, to take the hardware connection even further. In the meantime, use, expand and tear apart this patch, and have a blast!


This video accompanies the first installment of the series "Working With Hardware" on cycling74 dot com.

Sequencer for Livid Instruments' Code

A series devoted to building software for hardware.

working-with-hardware-livid-instruments’-code

mchenetz

Codeseq is programmed as a Java external and can be inserted into and Max and/or M4L Patch

codeseq-a-sequencer-and-translator-for-code

CodeSeq: A Sequencer and Translator for Code

robermann

Max/MSP enabled the auralization of several sorting algorithm's execution path: every instruction triggers an oscillator, tuned to a specific pitch.

Search Results