In the previous two articles, we approached looping in Live in two different ways. Both have their advantages, and each offers a distinct workflow. One thing they both lack, however, is some sort of LED feedback so that we can tell what’s going on in Live by looking at our SoftStep. In this article we will look at using the Live API via Max 4 Live to set up LED feedback.
To follow along with this tutorial some experience with M4L and the Live API is helpful, but not necessary. All of the examples will be given with very basic techniques, but also with some more advanced things (some javascript, some iteration and checks through the API). A good place to start is the Live Object Model (LOM) documentation provided by Cycling ’74. This gives an overview of how things are structured and where within your Live Set you can find things (tracks, devices, etc.). We’ll be walking through the building of a few M4L devices and will be using the sets that we created previously as starting points. You can get all the sets and Live devices RIGHT HERE.
Let’s start with the Looper Device. Open the LoopingSet_Loopers (or drag a Looper onto the first track of an empty set). Let’s focus on getting the state of the Looper on track one to control the LED on pad one of the SoftStep. Create a new blank MIDI track, set the output to SSCOM 1, and drop a default M4L MIDI effect onto the track and open it up for editing. We are using a MIDI device because we need to send MIDI messages to the SoftStep to control the LEDs. First we need to figure out how we get information from the Looper on track one into our M4L device. To do this we need to figure out where within the API the parameters of a device live. The API is organized in a hierarchical way, with the Live Set at the top. The Live Set has children, like tracks, and tracks have children, like devices. To find things in the API we need to define a path starting with the Live Set and then follow it down the structure until we arrive at our intended object. If we find device parameters in the LOM and trace it all the way to it’s origins we see that they are children of a device, which is a child of a track, which is a child of a Live Set. So the message we would send to a live.path object to get the device’s id (the unique identifier that gets assigned to everything in Live) would be ‘path live_set tracks 0 devices 0’ (all children that are part of lists are indexed from 0) .
This points to our Looper device, but it doesn’t give us much information about what we should observing. In order to get the state of the Looper we need to look at one of the device parameters. The construction to the left allows you to increment through the device parameter list, and get the name of the device printed to the Max window. If you move the number box up you will eventually see a device parameter named ‘State’. That’s the one we want! Now all we have to do is send that path, ‘live_set tracks 0 devices 0 parameters 1’ to a live.observer, and ask the observer to report the property value. You will see that when you trigger the Looper the live.observer will report a 1 when it’s recording, a 2 when playing, a 3 when overdubbing, and a 0 when stopped. This is plenty of information to set up some LED feedback on the SoftStep.
There is a section in the SoftStep manual that covers remote LED control, but the basic implementation is this: CCs 20-29 control the red LEDs, CCs 110-119 control the green LEDs. 0 = off, 1 = on, 2 = flash slow, 3 = flash fast. We will want to set up a conditional within Max that sends the appropriate CC messages depending on the state of the Looper. For instance, if the Looper’s state is 1 we will want to send CC110 with a value of 1 to turn on the green LED, and CC20 with a value of 0 to turn off the red LED. That would look like this in Max:
To get LED control over all of the states you’ll have to flesh out that select object construction to include cases for all the states of the Looper. Then you will have to duplicate the code, adjust the track it’s looking at and adjust the CCs that it sends out (the pair of messages triggered from the select object). I am a fan of doing things like this in JavaScript, so you will see an alternate implementation in the LooperObserver_Static device. To take the implementation one step further and make the device look for Loopers on a given track, take a look at the LooperObserver_Dynamic device. You can see how to iterate over devices in a track and just find the Loopers, regardless of where they are in chain of instruments/effects. This opens you up to more possibilities when working with how your effects chains are organized.
The other looping solution we explored uses clips in Session Mode to create a looping environment. We can use the API to observe the state of tracks and clips to get LED feedback with the SoftStep. If you open up the LoopingSet_Clips project you can see this in action. On the last track (Output to SS) there is a device that gets the playing clip (or lack of a playing clip) and then outputs information based on the state of that clip. The guts of the device are very similar to the devices we made previously, but the way that we get the information for the LEDs is a bit different. We are dynamically assigning observers to new objects in the API (in this case clips) by information gathered from other observers. Things like this take some time to set up and get right, but the reward is very tight integration. Take a look inside the Observer patchers inside the device if you are curious about these techniques for navigating the API.
Hopefully this series has given you a good starting point for investigating your own looping setup. The API and M4L give you access to some tools that can provide some great two way communication between your hardware and software.