Marsha Vdovin

WaveDNA is a Toronto-based company that has achieved great success with their Liquid Rhythm software.  This innovative beat generator, which enables users to access the building blocks of ten quadrillion rhythmic patterns, integrates seamlessly with Ableton Live and is now updated to version 1.3.4 which introduces Ableton Push hardware integration.  We sat down with the creators to discuss their use of Max in the inspiration, development and prototyping of Liquid Rhythm.

DB: David Beckford, Lead Inventor and Vice President of WaveDNACM: Chris Menezes (behind Dave), Junior DeveloperAS: Adil Sardar, Lead DeveloperHW: Hui Wang (on laptop screen), Senior Software DeveloperPS: Peter Slack (far right), Senior Software Developer and IT Manager

Can you tell me a bit about WaveDNA and your products.

DB: WaveDNA is an entity to commercialize our Music Molecule technology. The Music Molecule provides structure to raw MIDI by grouping notes into modular containers. The containers preserve whether the notes occurred on strong or weak beats, for example, and in this way, the Music Molecule can capture relationships between related notes. Standard notation can capture some of these relationships, but not in the same modular, re-usable way as our system. We believe our system is more suited to today’s production environments, and doesn’t require a textbook to grasp.

Now, the problem, that I found 25 years ago when I was studying composition and first working with MIDI, was that these two, standard notation and MIDI, can talk past each other in certain ways.  There needed to be a way to take concepts from both and work towards a productive middle ground.  It took an evolution from that point to get things going.

So we’re a pattern language that can analyze and create music.

I learned from tutorials on line and just hands-on monkeying around with it.


PS: Max was Dave’s original architectural choice.  I think the graph model or design pattern approach in Max sort of lent itself to rapid prototyping, and Dave had experience with earlier products that he invented with Max.  He used it back in the days when he was working at the University of Toronto Mississauga with collaborators that we still work with through Rhyerson’s SMART Lab.  So even at that time, we’re talking about seven or eight years ago, Max was state of the art and very useful.

Personally, I wasn’t aware of Max before I came to work with WaveDNA.  So I learned from tutorials on line and just hands-on monkeying around with it.

DB: Peter manages the architecture and the substructures of Liquid Rhythm.  He makes all of the end processes talk.  And he was the initial person who pioneered the Ableton, Max for Live Bridge implementation, which is really popular among our customers right now.

So you used it to prototype your product?

PS: Yes.  Our prototypes were purely in Max.  We had other elements of the product that Dave developed in Java.  So my task was to sort of marry both of those together, so that the audio side of it was prototyped in Max, purely.  And it’s actually part of our production product.

'magical language’ where you connect boxes with lines


Which part of your final product is still in Max?

PS: Our final, what we call the Audio Engine, which is a separate process, and it’s Max code.  It also has our WaveDNA brains, Java brains, embedded into it.

We still use Max to prototype.  We have new products that we’re prototyping with Max right now.  Dave is working on a prototype that’s pure Max.  We’ll eventually integrate it with the rest of the system, including the Java.

One of the original ideas, even five years ago when I came on, was to integrate the WaveDNA product with Ableton’s script-ability in Max for Live.  Then, about a year and a half ago, we prototyped what we call Liquid Clips and it’s using the Max for Live scripting engine in Ableton Live 9.

We basically took our audio engine Max patch, plopped it into Ableton’s framework, and the product was prototyped within about a day and a half with a few adjustments.  Of course, we’ve done a lot of work since then to optimize and fine-tune it to the product it is today, and that is the work of Hui who continues to maintain that product.

So Max has not only been a preferred prototyping platform here at WaveDNA, but it also ends up in our final products, in various forms.

And Hui, you're the Senior Software Developer.  How did you get started with Max?

... increase beat complexity with all the features that we provide without breaking the musical groove


HW: When I started off here at WaveDNA, I actually didn’t know much about musical concepts nor even heard of Max.  I came from a low-level programming background and when I was first introduced to this 'magical language’ where you connect boxes with lines, I thought at first “what is this craziness and how can it possibly be used in a music software?”  But after using it for a bit, discovering it’s quirks and just getting my head around how different things work, it dawned on me that this is actually a very powerful and unique programming paradigm.

I took over the Max for Live proof of concept that Peter started and productized it in preparation for consumer consumption.  I came in and was able to quickly learn the flow of logic since it’s so easy to see how the patch worked at runtime.  This allowed me to clean things up and make the code more efficient, improving the way we interfaced with the Live Object Model.  Max also provided me with the versatility of writing programming logic using Max objects, JavaScript as well as Java classes.

More recently, my primary focus is diving into the control surface portion of the Live Object Model.  With control surfaces, we’re actually able to talk directly with MIDI devices like the Ableton Push.  We’re able to take over buttons, assign our own behavior to them such as lighting and embedding Liquid Rhythm specific functionality.

It ties the Push hardware even closer into a user’s workflow, so they can quickly make a beat within Live, and then switch over into the Liquid Rhythm Max for Live patch, and increase the beat complexity with all the features that we provide without breaking the musical groove.

DB: Let me introduce Chris.  Chris is our Junior Developer, but he’s growing more senior day by day.  The Max for Live device platform is of great interest to us. So Chris took on an experimental project called VQ, which is a velocity shaper for MIDI.  He prototyped and built a plug-in from design up to full product concept for us to test out how that system is going to work.  So he’s going to explain his experience with that, and his introduction to Max.

CM: I was looking to learn something new.  Then I was given the pleasure of working with Max.  So much like my good friend Hui, I just looked at all the boxes and I thought, “Whoa, this is something different.”  We just connect and connect objects.

Eventually it started to hit that prototyping was really easy as opposed to programming languages that I worked with before.  I don’t have to do much set up; all these objects are premade.  So it’s very easy to just try your ideas and test it out fully.

Of course I couldn’t always find a pre-existing object.  So that’s when we started diving into the world of MXJs and all that, to get the full functionality that you want out of something.

Eventually by digging around, and just bouncing off the walls, it ended up working.

DB: Although each of one of us takes on different projects, when we’re all in the main developer area we tell our war stories for the day.  So I’ll come and say, “Hey, I found this new object, this, this, this,” or Chris will work at something and I say, “OK, that patch is way too messy and you’re using this technique.  Try this instead,” so we’re able to exchange ideas.  Hui taught me some tricks about color-coding his patch cords, which helped me out.

We have different philosophies and different things we bring to the table.  We always look for things that work, despite the chaotic unpredictable circumstances to work in.  So we're constantly retooling and reworking things.  We want to find the objects or the techniques that have made it through the first round of failure.  Because, if we can test an idea and it can fail quickly and we can understand why, then we can re-implement that solution later on.  And we can spread the knowledge through the company.

So basically, I solve some of the fundamental conceptual architectural issues with my designs and then I get together with Adil, the Lead Developer at WaveDNA, we communicate and figure out how to transfer prototypes into different commercialization stages, and then Peter, Chris and Hui handle different parts of our pipelines, and we can work in modular teams that way.

Dave, how about your personal experience with Max?  You've had previous interactions with it?

DB: Personally, myself, I’ve been a huge Max-head, right from the beginning.  I used to hang out at a store in Toronto, called Saved by Technology.  It was a great place where every week some strange new thing came in.

Max just completely impressed me because I realized, here’s a language that you can use to build other things, using this world of objects and patch cords.  And unlike most other programmers at the time, I was self-trained.  I had no formal programming background.

As a kid, I used to program in DOS, in this modular language called Foxbase Pro that I used to structure data.  Using that language, I was able to develop some of my early theoretical ideas.

That language was very modular.  And there was a concept from that language that I was able to carry forward.  It was the concept of indirection; that I was able to take a cell and change it’s assignment programmatically.  So that means I could add dynamic placeholders to do functional things on my pre-existing data structures.

Foxbase Pro is dead and gone, but that concept stayed with me and that it’s a good way to work.  So when I saw Max MSP come out, it actually was a perfect fit for my Foxbase Pro background, which is kind of cool.  I had Max personally for a while, but I wasn’t sure what to do with it.

...learn how to bring my concept to reality


When did you decide to use Max to explore and develop your ideas leading to Liquid Rhythm?

As far as the first major business step towards what the company is today, actually began on 11/11/01.  There was a Harvestworks convention in New York City and David Zicarelli was going to be speaking at this convention.

This was a developer conference, and that was the year I had decided to fully commit to starting things going.  So my first business activity to move my business forward was to meet the wide world of Max people at this developer conference, and learn how to bring my concept to reality.

I get to the conference and there are maybe 12 people there.  A woman named Dafna started the class, and people were creating a patch called Random Atonal Crap.

Now, for me as a software developer/prototyper, I was screaming on the inside “I don’t want to do this fluffy artistic performance stuff.  I want some real, hard, like solid meat to get into.”  I was complaining on the inside, and I think I even complained on the outside at one point.

But the highlight for me was when David Zicarelli came in.  That was where he first introduced that JavaScript was coming to Max.  He showed a prototype of that, and that totally opened the door for what’s possible today.

Later, I had dinner with David Zicarelli and I asked him, “How do I make an interface patch communicate to a business-layer patch?”  So he showed me some things about coll objects and how to move data around.  It was through that conversation and developing early prototypes that ultimately led to the company’s creation.  It also informs and helps me manage my process today.

My goal for all of my code is that it must die a noble death.


I imagine your use with Max has evolved over all these the years.

My role in the company is advancing the theoretical core of the Music Molecule.  When I first started working on Liquid Rhythm, I did a lot of my designs on white boards and sketching things out.  And because everything was new, I just let the designs go raw.  There was a lot of improvisation in the early days and this led to a whole community effort of what Liquid Rhythm is today.

Now that we’re moving into our second product, I need to fully specify things ahead of the game because I want to introduce things in an ordered fashion.  So how I use Max now, it’s essentially a living design document.

One of the programming design languages for structuring the object relationships —an old one that was pre-UML— was called Data Flow Diagrams, where you have data entities and they’re connected together by wire.

That was a great language for me to design in.  But then when I look at Max, I can see that it is essentially a Data Flow Diagram.  I view my Max programming as halfway between linear programming and designing an electronic circuit.

I try to have a fixed set of design tools when I’m prototyping.  My goal for all of my code is that it must die a noble death.  I write things to iterate through systems quickly, and I have to build a system with a current set of assumptions and get that working, knowing as I evolve and move on to other systems, that first system can fail.

So I count on all my code failing at some point, unless it has a screaming reason to stay alive.  Sometimes the only purpose for things to come alive is that you can see how it works, you can see its moving parts, you watch how it falls apart and you study why.  Then the next iteration around comes together in a better manner.

So by developing design processes using a few core trick tools that allow me incredible flexibility in building modules, I can build complete systems, rip them apart, rebuild them, rip them apart, and refine a very chaotic process in a very linear way.

With this latest incubating project involving a tonal patch, I have about 50 sub patches under the main project and all sorts of things working together.  But the benefit of things right now is that with this fully specified patch in Max, now I have an ultimate knowledge transfer tool for the company.

I like that idea of a 'knowledge transfer tool'.

For me it’s a living data document that allows us to specify our theoretical concepts.

So now, with this central Max document, one path is for it to turn into an Ableton Live patch.  Another path is for it to add extension into the existing Liquid Rhythm program or Liquid Clips applications.

It can also be used as a living developer document.  As opposed to saying, “Here’s a whiteboard sketch, God bless you and figure this out.  And oh, by the way, you did it wrong,” I can now say, “OK, here, this works this way, make code that behaves like this.”  And we can talk about that.

Now this shiny new thing that hasn’t been in existence before now has a way to communicate to everybody in a way that they can understand.

I spent 25 years looking at what’s between the MIDI notes.


What was the inspiration for Liquid Rhythm, and especially the user interface?

DB: Well, the great thing that I saw lost between standard notation and MIDI was that standard notation allowed you to specify relationships between the notes in a compositional manner.
So if you scored a small motif —think of Beethoven's 9th, if you like —you could then take the basic pattern material and re-deploy it under different transformations to create motivic variations that evolve that motif into a series of phrases or a full piece.

That allows people to put together complex structures.  But if I take that same data that has all those relationships, and I take that same score and look at it in MIDI data, it’s now turned into chaos.  You could see all of those relationships in standard notation, but when you look at that same information in MIDI, it’s gone. All you are left with is a spray of isolated notes — unconnected atoms instead of structured molecules.

Now the good thing about MIDI, it is performance accurate, and I can see what I play.  But what MIDI leaves open is the question of why?  Why should I put this note in this place as opposed to that place?  Why should this note be this long, why should this note be this loud?  Why, why, why?  It’s all extremely arbitrary.

I spent 25 years looking at what’s between the MIDI notes.  The spaces between the notes contain the relationships between note to note.  And when you look at these relationships, you can decode and pose these relationships into a set of repeatable patterns.

The first layer of these patterns occurs at the eighth note.  The second layer of these repeatable metric patterns, occur across a bar.

In wave theory, waves oscillate from strong to weak in a cycle.  So with Liquid Rhythm we have two types of core waves.  We have a binary wave, which alternates between strong and weak, and we have a ternary wave, which alternates between strong, medium, and weak.

We then use these core patterns to describe every temporal relationship across an eighth note, and across the bar at different resolutions.  This turns into an adaptive grid.

Can you give us an example of how this grid works?

Well, the general problem that people have when they play in MIDI, is to record something into MIDI, and then want to quantize it.  The problem is that music that is actually performed, rarely stays at one quant for very long.  So now the question comes, at which quantization do I quantize it with?  If I quantize at 16th, it’s going to match my 24th, and vice versa.

So the solution that the Music Molecules allows is an adaptive grid.  Instead of you moving the music to a pre-existing arbitrary grid, we have an intelligent grid that finds your notes, where they are, and says, “Well, here’s relevant information.”

And once we can find the initial patterns that make up this underlying bar of music, within our coordinate system we can then allow you a rich set of permutations to transform your ideas.

What I find these days, in talking to people who talk about the philosophy of music making, is that with tools today like Ableton’s Push and various arpeggiators and what not, it’s easy for people to come up with their first idea.  I can play around on a keyboard, I can bang out an idea, I can come up with something that sounds good.

The hard problem lies in how do I come up with my second idea, and how closely is it related to my first idea.  When you look at blocks in space, that’s a completely arbitrary thing.

Our goal with Liquid Rhythm, on one hand is, yes, we want to introduce a tool that makes phat beats and helps people with what they’re doing.  But really, my underlying motive is to introduce an interactive, intelligent music theory to help people see underlying design patterns in music beyond the MIDI data as traditionally shown.

All of the things I’ve touched on are explicit in our user-interface and our Music Molecule ‘data visualization and representation system’, so to speak, which evolved over a number of iterations.

We have other products in mind that are going to build on this theory.  People that are using the tools in Liquid Rhythm, are going to see the same theoretical elements coming up in our next tools, and that will give them a bridge to understand our new conceptual developments.

We’re a music software company that makes no sound.  But if we can give people ways to put notes in places where they normally can’t with MIDI editors, then that’s an interesting value proposition.  It allows people to shape musical concepts beyond their playing capabilities, and I think that would open up all sorts of opportunities all over place.

You’re never really alone because so many other people have the same challenges and problems.


Do you have any advice about starting an ambitious Max project?

DB: My advice is: keep plugging away at it — pun intended.  Keep digging away and be prepared for large portions of your code die on the way to better solutions.  It might be the wrong way today, but you’ll find the better way tomorrow.  There are so many projects and sub-solutions and bits and pieces of interesting code that you can take and use.

Now, on the flip side, that digging might take you into areas that you either didn’t want to go or might not want to explore.  So you have to be willing to be an explorer, yet you have to be willing at times, to just settle down and say, “I’m going to make this JavaScript work whether it kills me or not.”

Finding that balance is what we talk about, so we kind of have a Max developer support group and say, “Yes, I screamed at my code again this week.  I was horribly abusive, but I’m getting better.”  So we give each other tricks for how to deal with things and then we move on from there.

HW: I wholeheartedly agree with Dave about digging.  This language is one in which you just have to keep on going through it. Over and over iteratively until you come across your solution.  With Max, you are rewarded for tenacity.

Luckily there’s a global support group in the form of the Cycling '74 forum where there is a gold mine of information.  You’re never really alone because so many other people have the same challenges and problems.

You may not find a solution right away, but if you follow links and other’s suggestions, eventually you’ll come across something that you can think, “Oh, maybe that will solve my problem.”  Very likely it probably won’t, but at least it will give you some new ideas to try.  Because Max, as lovely as it is, will give you 10,000 ways to solve one problem.  You never really know which is the best one, so you just hope that yours is good, and if it works, it works, and just move on.

I hear a lot about how generous the Max community is.

DB: In some ways, I think the camaraderie that comes in the Max community is that this is a community of people on the bleeding edge.  Like everybody in the Max community, for the most part, is drawn to it because they want to try something that they’re not sure how to do in other languages, or haven’t been done before.

So of course people are going to run into problems and are screaming, because this is the land of trying things for the first time.  It’s that overall sense of heroics with, “Wow, you’re a Max developer.  God bless you.”

It’s really a philosophy as much as a coding language.

So, the big news, the release of a new version!  Can you tell us about your new update?

We have several avid cyclists at WaveDNA... during the summer time at least half of the office bikes to work. We asked Cycling '74 if they had any cycling gear/swag for our cyclists... this is what happened. 

Check out www.cycling74.com

Cycling '74 Bike Bells

In this unique interview the WaveDNA team, the developers of Liquid Rhythm reveal how they have embraced Max in all the stages of their software development.   

an-interview-with-wavedna

An Interview with WaveDNA

Gregory Taylor

We’re pleased to announce a major update of Jeff Kaiser's jk.push package of Max abstractions made with for interacting with Ableton’s Push 2 controller within the Max environment. 

The new release of the Push 2 abstractions have been extensively rewritten to use Max arguments and attributes that make configuration for your own patching quicker and easier, and a set of easy-to-understand examples are now included in the Max Extras menu. 

Note: This update means that these jk.push abstractions are not compatible with versions 1.1 and earlier of these tools.

The jk.push package includes the following abstractions:

A single instance of the jk.pushcore abstraction manages all connections between the ji.push abstractions and your Push 2 device.

You can access and interact with the 64 pads and buttons on your Push controller with live.toggle, live.button, live.menu, or radiogroup objects using the jk.push abstraction. It also outputs MIDI Note number, velocity, and aftertouch.

The jk.pushrotary abstraction allows you to interact with the Push 2 Rotary Encoders with live.dial, live.button, and live.text objects. It also outputs the MIDI Note number associated with the Rotary encoder, velocity (0 or 127).

The jk.pushribbon  abstraction allows you to interact with the Push 2 ribbon slider with live.slider, live.text, and live.button objects

The jkpushpedal abstraction allows you to interact with the pedal inputs on the back of the Push 2 with live.button and live.text objects.

This collection of abstractions is available and accessible using the Max Package Manager.

jk-push-example.jpg

Learn about the major update of Jeff Kaiser’s jk.push package of Max abstractions made with for interacting with Ableton’s Push 2 controller within the Max environment.

package-arrival-the-jk-push-2-abstractions-for-maxmsp-ableton-push-controller

Package Arrival: The jk.push 2 Abstractions for Max/MSP

gbravetti

When using hardware at some point you end on a wall you can't go through... Max allowed me to go through that wall countless times so far.

On this opportunity the wall breaker is Performer. Performer is a "Performance Master Snapshot Controller" programmed in Max, that uses the Ableton's Push controller to control a selected set of parameters on the Elektron's Octatrack, Analog Four/Keys, Rytm. 

I developed it as a tool to be used when performing Live with those machines. It still needs some optimisations in some areas but, so far so good, thanks Max!

performer-performance-master-snapshot-controller-for-the-elektrons-dark-trinity

Performer - Performance Master Snapshot Controller for the Elektron's Dark Trinity

andrej

Cycling '74 has recently given us some really nice updates such as the Mira update and the MPE & Blocks implementation. This is my project that implements the updates.

Granurise is a real-time Looper, Sampler and Granular synth which integrates with the outside world trough Ipad Mira, Midi–MPE & OSC.

•	»Human modulation« automation that follows a last gesture until a new one is recorded

•	Edit pitch, volume, pan, eq, density & scrub for each voice

•	Different windowing + design your own

•	Transforms the pitch without altering the speed of sound using the FFT transform

•	Slide can also control the position of each voice

•	Press can control the selection duration

Granurise is a real-time Looper, Sampler and Granular synth which integrates with the outside world trough Ipad Mira, Midi–MPE and OSC.

granurise

GranuRise

Darwin Grosse

So, to start off this October 2013 Push Development series, I start with a device that does something I like to call frequency mixing. I use frequency mixing a lot during live performance, taking a static track and using some interactive EQ tricks to create a more interesting mix out of a single loop.

What we are going to do is to create an 8-band EQ/mixer, then hook it up to the button matrix of the Push. With a little tweaking, you should be able to use this information to access the buttons for almost any use you can image!

Download the first version of the device here: 8BandMix-V1.zip

In order to make sense of the patch - and to help you understand the process of making a patch Push-aware - we are going to start with a Max-only patch, then add Push content as needed. So, we have to start off with a basic Max for Live device that provides all of the tools necessary for doing frequency mixing.

You will notice that this device is missing some of the controls seen on the video - most particularly the "smoothing" function and Push device selection. These are specific to the Push itself, so we are going to ignore them for now.

Looking at the basic patch reveals the basic technique. We have slider objects that control the overall volume of each of the EQ bands, controls that allow selection of the band "breakpoints", and the mysterious "8-cross" subpatchers that seen to be affecting the audio. Also, we take some values output by the 8-cross subpatcher and use them to light up a multislider object.

A few details to note. First, if you open the Inspector for the level slider objects, you will see that their range is set from 0 to 7 - a total of eight stages. Convenient, since the Push has eight buttons in the matrix for our use. In order to get a useful volume range (from 0% to 175%), I multiply the packed values by .25 - giving us volume values that allow for a decent cut or boost. The Reset button simply sets everything to 100% as a good starting point.

Also, in order to make our level displays "hyperactive", I have a vexpr object that multiplies the volume levels (reported by the left 8-cross subpatcher) by the value of the meters control. Since that meters control goes up to 10.0, it means that the display might be 10x higher than the actual volume; but as you will see, this is actually a useful way to interact with this particular visualization.

Finally, we can double-click on the 8-cross subpatcher to see what is inside:

Rather than using a filter or other typical EQ device, I'm using a set of cross~ objects to emulate an eight-stage crossover network. Since cross~ provides a 3rd-order - but fairly neutral - filter, using them in series works out. They also sound right to my ears for this particular application. If you aren't familiar with the cross~ object, you may want to refer to the reference manual or extended ref pages.

With this basic patch, you should be able to manually get some of the results that I achieved with frequency mixing. The next step is to control these changes with our Push device.

In order to make anything work at all, we need to find the Push among the devices that we have connected to (and recognized by) Ableton Live. While I could dive directly into the Live Object Model (LOM) - and I probably will do so later in the month - I'm instead going to use some Max code provided by Ableton's own Push Guru: Mark Egloff.

Mark has provided me with some code that he developed for his own use, and is willing to share with all of us. This breaks down the connection to the Push into easy, always-available tags, and is going to allow us to get our device going in a hurry. 

When you un-zip the file, you will have a folder that follows the "packages" format for Max 6. Place this folder in the packages folder of your Max distribution and you will have access to the code as a series of clippings. Let start our Live connection by using some of this code to attach to our Push device.

Within our device patch, open the contextual menu (Right-click on Windows, Ctrl-click on Mac), select Paste From... -> Ableton Push -> Global.ControlSurfaceSelector. This will drop the control surface selector code into your patch from the clippings file. This code fires whenever the patch is loaded, and will fill the menu with all of the available control surfaces. From here, we can select our Push.

For this patch, the only thing I want to see is the menu, so I remove everything else from Presentation Mode. Now, we have to tie this selection to the rest of the system. Select the Global.ControlSurfaceManager from the same contextual menu. It will take a while to load - this is because all of the "guts" of the system are in the few objects that will be pasted into the patch. Connect the selector to the message box that contains path control_surfaces $1 and you are ready to rock.

If you want to see if things are working, just hit the button matrix or other control; you should see information show up in the message box connected to the receive objects. 

Moving the menu into place (in Presentation Mode) gets us to this point: 8BandMix-V2.zip

Next up is input: we have to get the button presses from the button matrix and use it to set our slider values. If we look at the values being received by the r ---from_Button_Matrix object, we can see that any button press creates a four-number list. 

First number: The velocity of the button press

Second number: The column of the button press

Third number: The row of the button press

Fourth number: I don't know - but it always seems to be a 1! (Could it be the MIDI channel?)

So, we need to take these numbers, format them to the number range of our slider objects (0. through 1.75), split it out to our sliders and use the buttons to control our device:

Now, there is also a bunch of extra tooling below our splitter: this is what allows us to change the speed that the sliders move into place. When a value is set, it is combined with the value of the smoothing control, then run through a line object that slows down the value change. Once you connect this to the sliders, you will have the input control necessary to manage the sliders appropriately. 

Moving this new patching into Presentation Mode gives us a "nearly complete" device: 8BandMix-V3.zip

The next step is going to seem pretty simple, but is actually where a lot of the design work goes. We need to provide a user interface for our process on the "face" of the Push; to do that, we'll take over the button matrix for our purposes.

We seem to only have added one object, but it is the core of our interface - a subpatcher that breaks apart the current contents of the volume message, determines what buttons need to be lit up, then sends "light up" messages only if the value has changed. This reduces the number of messages sent to the Push, and keeps our data traffic as low as possible.

We also have to do one more thing: we have to take control of the button matrix before we can write to it. You do this with a grab message, and you undo the process using a release message. I've added these to the patch and to the panel of the device; now you can grab the Push, use the button matrix for control (with visual feedback) then release it back to Live's control. The end device from this stages looks like this:

At this point, we only have a few more details to clear up. First of all, we need to properly capture and release the Push device. This means more than using the grab and release messages - we also need to prevent the system from using the buttons when we aren't grabbing it, and we need to refresh the display whenever we enable/grab the matrix. We are going to use a trigger object to manage the order of messages.

Now we are properly managing our attachment to the device. Another detail we have to work on is the display when our device is in focus. This is done by changing the "order" setting in the inspector for our UI controls. In this case, what we need to do is to make the smoothing control the first available (left-most) control; we do this by setting its order to -1.

Next, we set the filter cutoff/breakpoint controls to 1 in order to put them to the right of the smoothing control.

The last thing I've done is to expose the menu-loading button to the user interface so that I can get the Push when I've plugged it in after I start Live. This gives me a final device that looks like this:

You can download the final version of the device here: 8BandMix.zip

YouTube viewer "You & We" asked if there was a way to use this as a frequency crossfader. This was a great way to think about the device, and something that I wanted to try. The way we are going to approach is is to make the 8BandMix device into a "Master", and then create a "Slave" device that will receive changes from the Master and either match or invert the results to create either a second mixer or a crossfader.

The first thing we have to do is change the 8BandMix device. This is going to be pretty easy - all we have to do is to take the necessary data (the slider and crossover values) and send them globally to any receiving device:

We use the send object with a name global8BandMixControl - without the leading --- - in order to have this named the same for every device in the system. This gives us access to the values that we will use in our slave device.

Now, we can create a second device that contains much of the "guts" of the 8BandMix device, but doesn't interface with the Push - and doesn't provide access to controls that will be managed by the master device.

You will notice that we receive the data from the master, then propagate it to the places it needs to go. From there, we have to allow this device to either mirror the master (Normal mode) or flip/crossfade the master (Inverted mode). To accomplish this, we use a ggate object to determine if a calculation occurs, then that result is sent to the slider system.
Other than that, we should be good to go...

There are a few limitations to using send objects in this way:

There is an undefined delay time between a sending and receiving of a message. So you won't have sample-accurate crossfading.

If you insert a Slave after the Master, but have already changed the crossover points or volumes in the Master, this change won't be propagated until they are changed again.

There can be some performance problems with sending large streams of data over a send connection; this may not be a problem in this case unless you are very active on the Push.

Since this uses a named send object, it means that you can only have one Master device in each Live set.

Hopefully this device is still useful, or maybe you'd like to eliminate some of the problems (using speedlim and metro to resolve some of these issues); in any case, I hope this has been an interesting experiment.

Here are the devices: 8BandMasterSlave.zip (Note: Updated Nov 6, 2013 with proper receive name and slider scaling!)

So there we go - our first basic device for Push, but one that is actually useful in the Real World. Feel free to send me a note with suggestions for improving the Push tutorials. And thanks for watching!


Search Results