About MC - A brief interview with David Z.


    Like many of you, I was excited to see David Z.'s presentation to the 2018 Ableton Loop event (ably assisted by Tom Hall) put up on the web for all the world to see. I was — of course — curious to get a guided tour of the new features for Max 8. But I had another reason — I knew that it was one of David's "personal" projects... something that had really sparked his imagination in the course of its development.
    The Loop presentation was a great introduction to MC. If you haven't seen it, it's worth a look:

    Multi-channel audio as creative space: Inside Max 8’s MC | Loop

    In the course of my undertaking my own decidedly non-exhaustive personal series of semi-tutorials based on my looking for ways to use MC in my own practice (in the hope of inspiring some of you), the opportunity presented itself one day to ask David a few questions that I'd always been a little curious about: not so much questions about a specific feature, but more about his own experience working on MC and using it himself. It occurs to me that there may be some of you out there who've wondered about similar things, so I asked David if he'd mind if I shared his answers with you. Was the creation of MC for Max 8 a programming project that grew as you thought about it and solved the initial challenges? If so, what did that look like? At the time I had the first insight that led to implementing MC, the concept of patch cords carrying multiple channels of audio had been a fantasy we had talked about for a long time. It just seemed like too much trouble to think about given the potential benefits, which mostly seemed to be around convenience more than anything else, so no one really took it too seriously as far as I’m aware. In other words, it was one of these things that needed to exist before it became interesting. And since it didn't exist, it wasn’t interesting enough to make it exist! So it took something of an accident to get out of that loop.
    The implementation insight came when I was trying to provide a programming example for Alex Harker who was working on a frame-based signal processing library in which his patch cords described a new kind of connection between objects. It wasn’t a traditional Max or MSP event or signal connection. To illustrate the idea that patch cord connections could mean anything if the two connected objects agreed about the special meaning, I decided to write some sample code for Alex in which a patch cord secretly carried four channels of audio between two specially designed objects. Those objects were more or less mc.pack~ and mc.unpack~. The moment I knew I was onto something was when I selected my special patch cord and deleted it and all four channels of my test audio went silent all at the same time. We have many ways to build up complex sounds with Max so hearing the four channels wasn’t that exciting to me. But to delete one patch cord and have four channels of audio go away at the same time — that was something I had never experienced before. I remember it being around 10AM on a Sunday morning that I got this example working, and then I was so inspired by this patch cord deletion trick I took a look at the existing MSP code and within a couple of hours I had figured out how make multichannel signals work.
    The next thing I did was make some multichannel versions of existing MSP objects like cycle~ and *~. Then I thought to myself, “how am I going to test that this crazy stuff is actually working?” This question of how to acquire test data has in my experience led to some great ideas. For example, in the patcher, typing the ’n’ key to make a new object was added by Rob Sussman just so he could have some objects to patch together.
    Anyway, I thought what better way to test that all 60 channels of this multichannel oscillator are working than to generate random frequencies for each of the oscillators? That led to the idea of deviate, spread, and so on.
    The next big breakthrough that Joshua inspired was to focus on making an invisible wrapper so that as many existing MSP objects as possible would not have to be rewritten to be MC-compatible. Once this started working it became clear that it was the combination of the wrapped objects and the multichannel patch cords that was opening a new conceptual space of audio channels that I had never imagined before. I would never claim this multichannel space wasn’t apparent to other people, just that it wasn’t apparent to me. Traditionally when I thought of multichannel audio I thought about spatialization of the output to multiple speakers. This was an entirely different idea.
    MC was a personal project for you (at least at the beginning), so I’m wondering what you use it for, and what places using it has taken your own interests and work…. I think there are two personal interests I’ve discovered as a result of playing with MC. The first is what I would call “cheap orchestral writing” illustrated by the idea of being able to evolve dozens of channels in complex ways that I would otherwise have had to score by hand. Suppose I have 100 voices playing C in unison and I want them all to move to playing A. Rather than switch them all at once, what if I “propagated” the change probabilistically over some period of time? This is an example of an effect that previously would have had to be written out in a score. But if it’s now “cheap” — and by that meaning it’s something I control with an automated process rather than specify by hand — then I can explore propagation as a creative space. What do different time periods of propagation sound like? What does propagating chords sound like? What about propagating changes in timbre? What if 90% of the voices change right away but 10% are holdouts? Then you get into detuning, per-voice reverb, and so on. It’s interesting how each of these orchestral effects seems to have a number of channels beyond which you can’t hear a difference.
    As a general rule it’s often around 50. The second idea I have enjoyed playing with is what I would call independent instrumental systems. As a piano player I see the instrument as an array of 88 mostly independent sub-instruments — key, action, hammer, string etc. All these systems share a common resonating body but for example if I put a dime in between the strings of F# above middle C, then that note is always messed up, which leads to ideas I would never have considered before within the computer domain. Having “88-note polyphony” is very different conceptually — it doesn’t map to the constraints in the real instrument. You probably won’t think about permanently damaging that F# and then playing that new “instrument” — indeed, if you merely look at it as a case of polyphony, you could theoretically play as many F#s as you want, which is just not possible in a real instrument.
    Maybe what these two ideas have in common is the reintroduction of musical organizing principles from the real world that I find meaningful — not just how real instruments work but also how real people play them. In both cases the idea of parallel independent systems seem to match the way I think. A long time ago I gave this talk about all computer music sounding the same because the only salient compositional variable it seemed anyone was dealing with was timbre. What I’ve realized — at least for myself — is that maybe this sameness comes about because of an attempt to think about designing one sound to be as intricate and complex as possible. I could never get very excited about that. In fact until MC came along I was never really interested in “sound design” at all. Complexity for me came from putting people together and seeing what happens between them. My teacher Bill Dixon always said, “the music happens in rehearsal.” To illustrate this point, I remember once rehearsal of an ensemble where he told one drummer to play in 16 and the other drummer to play in 15. After we played the section of the music, Bill noted, “Now, I know they couldn’t never actually manage to play this correctly, but I wanted the sound of them trying to do it and failing.” This is a kind of complexity that’s really hard to experience if you’re focused on that one awesome timbre. I guess I needed a space where I could set up a bunch of things to crash into each other.
    Now that MC is out in the world, I’m curious about whether there are any uses to which it’s been put by others that have surprised you…. Pretty much everything surprises me! I was really focused on developing the current set of features based on my own idiosyncratic ideas, so it’s been wonderful to see how it’s been possible for other people to express themselves with MC. It makes me think, “maybe I’m not the only freak out there…”

    • May 27 2021 | 3:59 am
      Where can i get these patches ? Kind regard Dietmar
    • May 27 2021 | 4:56 am
      Click here and scroll to the bottom.
    • May 27 2021 | 4:52 pm
      this article has been bothering me for a couple days to the point where i’ve considered it carefully and have to say something about it, so please forgive me, but i have to be honest: this particular article seems not so helpful or informative, but more like it's just a byproduct of growing too much ego(it's great when external companies/organizations interview the CEO of a company to get their thoughts on their own work, but when an employee of the same company interviews the CEO to post as an article on the company site... the company/culture can start to feel salesy to a self-serving and even narcissistic degree). and then as i notice there were no relevant patches or newer examples provided with this particular article, it really brings that feeling home for me(the loop presentation was years ago, we all know David Z. has a beautiful mind for innovation already and well before any of the MC-based innovations… would’ve even been nice to see some examples of use-cases that proved surprising/interesting, instead of just ‘pretty much everything’, or else maybe hold off on the article until you do have more ideas on that… by the end of the article, it just read like Cycling74 remains a bit insular). also, if you mention others like 'Alex Harker' might be most considerate if you drop a link to their work or site(as i've just done there and also here).
      i understand it's just my(probably more insignificant than any other) opinion, the article also had a different intention than being like a tutorial or introduction, but i only write this here, because i truly and deeply hope Cycling74 will avoid any ‘salesy’ feeling in its ongoing direction(it’s remained quite respectable more than most other businesses in this sense so far, that’s why i felt i needed to share my opinion here at all), so i hope you’ll all consider these things more carefully in the future. thanks for your time and consideration. edit: would've also been nice if they posted a link to Harker's FrameLib - even just the Github(if not also the emerging Forum) ^things like these left out, prove the article to be very insular and incomprehensive
    • May 28 2021 | 11:39 am
    • May 28 2021 | 8:24 pm
      I disagree (respectfully) - any discussion on the origin and philosophy behind MC is welcome. Not everything has to come with patches!
      I had no idea MC was a project of David's, so that alone was illuminating for me. Any more interviews like this would be most welcome.
      Edit: It's also interesting to me to see any influence of Harker's FrameLib, even though it's still early days. I'm keeping an eye on it to see what effect it will have on the community, and am excited to see what will happen. This is an intriguing early effect of that work. (GitHub: https://github.com/AlexHarker/FrameLib, Forum: https://framelib.discourse.group/login)
    • Jun 23 2021 | 12:57 pm
      Thank you so much! For me this is so inspiring. I am really looking forward to continuing exploration of MC.