Gregory Taylor

One of you kind souls out there emailed to ask me why I titled this series of MC tutorials with the word "journey. " That question is a perfect place to start this particular tutorial.

I used the term as a way to play with your expectations as a reader. The word "tutorial" has always suggested to me that there’s fixed (or organized) information in play, and it’s also often the case that that information is aimed at someone who either knows next to nothing or someone who knows everything but the tutorial’s specific information. In my experience, there’s a universe of difference between those two points, and it seems that we seldom make the process of learning by going where to go a part of the subject. I decided that I’d structure my MC tutorials to represent how I try to make my way not from ignorance to mastery, but from ignorance to idiosyncrasy. Because that’s how I really work, and I suspect that that’s true of a lot of you, too. I wanted this particular series of "tutorials" to include ideas such as "Your mistakes can lead you somewhere interesting" or "There's nothing wrong with building patches to help you to figure something out - they can be a starting point for something else."

Thanks for being willing to follow along in this series (even when I’ve gone places that might not be points along your path). I’ve tried to take some shortcuts by borrowing liberally from earlier tutorials I’ve done here because it saves time, and also because that, too, is how I usually work. Let's get down to it. 

The things you pass by and the things you return to

The first part of this series on exploring MC began with my trying to figure out how a feature of the amazing MC tools worked, making a patch to explore it, and suddenly seeing something that sent me off in a direction I hadn’t anticipated, which became the second part of the series. Not exactly the stuff of a linear tutorial, huh?

In terms of figuring out the MC spread, spreadinclusive, and spreadexclusive messages, I realized at some point that I was looking at floating-point numbers that described something specific - frequency ratios - rather than interestingly spaced number values given low and high range information. While I’d like to claim that I saw that the second I had my little spreader investigation patch up and running for the first time, I’d be lyin’, pure and simple. 

In truth, it didn’t happen until I saw a very specific number come up when typing low and high values in and selecting the kind of spread message to apply (If you’re curious, the number was 15/8 or 1.875, which is a major seventh interval in Just Intonation - an interval I really like). Looking back on that moment of insight now, I feel a little silly… I’d been staring at perfect fifths (3/2 or 1.5), perfect fourths (4/3 or 1.33) and perfect thirds (5/4 or 1.25) and not seeing them for more time than I’d care to divulge. It was the process of tweaking and playing that brought me to the point of departure. After that, coming up with pitches to tune my MC banks of sign waves was nothing more than an mc.*~ object that let me set the base pitch of my oscillators and I was off to the races.

This tutorial has its beginning in a patching error. It happened while I was working on this patcher used in the early part of the previous tutorial. Here’s the original patcher with my original error intact:

At some point, I went back to working on the patch, opened it, and clicked on the startwindow message box to turn my audio on. Rather than the chordal stack I expected, my patch emitted something between a pop and a click. I realized my error right away – I’d forgotten to set my patch up so that the root note frequency number box contained a multiplier value for the ratio values. But where was the pop/click thing coming from? When I typed a value of 100. into the number box, everything was fine. But I did notice that when I clicked and scrolled the number box for a value in the single digit range, I heard a pattern of clicks spaced across the found field.

...and that’s when the light went on. I remembered an interesting talk I’d attended at an Ableton Loop event with my pal and colleague Tom Hall, where the presenter discussed the notion that two oscillators tuned to a consonant interval (say 440 and 660, which is a perfect fifth) and then lowered into the subaudible range will result in polyrhythms — in this case, a pattern of three against two, since the frequency ratio of the two pitches remains at 3/2.

Thanks to my error, I was looking at a nifty little MC-based polyrhythm generator (And here’s the interesting thing: I noticed the clicks because I’d saved my patch with the sawtooth waveforms selected. Had I saved with sine waves selected, I’d never have heard the clicks and made the connection).

Converting my original error-based patch was simplicity itself, since I’ve used the patching necessary to convert phasor~ output to bang messages for a very long time. I lopped off the top of the patch since I didn’t need any of the waveform selection logic for my generator.

I substituted an mc.phasor~ object downstream of the root note frequency multiplier and added a few scope~ objects to view the waveforms and a trio of MSP objects: change~, ==~ 1., and edge~ (to generate the bang message).

The result was an interesting and wildly variable rhythm generator that it made up for the embarrassment at my original programming infelicity. As the Oblique Strategies say,

Once I had that, the next step was to do what I suppose a lot of MC users do: since N versions of something is great, a lot more of N ought to be a lot greater, right? I’ll spare you the next hour or so, and move on to my personal answer: It might be better to look at different ways to spread my subaudio values out rather than creating a patch that channeled the ghost of a stage full of Buddy Rich clones working their kits.

So it was back to using Max’s in-app search to take a look at what else I had at my disposal in the MC theme park. And sure enough, there it was — a completely different way to specify outputs in MC, based on the Harmonic Overtone and Undertone series!

Sweeeeeeet. Once again, time to figure out how these two messages work by creating a patch to test them out. It didn't take long to patch up a bit of MC that would generate harmonics and subharmonics and let me swap between them. And — of course — I kept that magic trio of objects to translate clicks to bang messages. Here's the results: the harmonics_explorer.maxpat patch:

The results of this reminded me of a very old Steve Reich piece — which, to my knowledge — is the only one that used electronics. It was originally created as part of the Bell Laboratories partnership with artists and composers. The phase box divided a single frequency and then assigned it to notes. 

It’s what the patch harmonics_player.maxpat patch does, in fact.

The final minor epiphany here came from doing something I do all too often: spending time listening to the output of the systems I’ve set up. Yeah, I know — I should just record everything, put out my piece/mix of the week, and move on if fame and fortune is what I’ve got in mind.

Instead, I tend to sit with what I’m making - listening for patterns, watching the UI fold, spindle, and mutate, and waiting for what comes to mind. Quite a lot of the time, one emerges from that practice having sat and listened and looked and that’s it. But sometimes, something clicks….

As with my looking at the numbers from a spread message in the very first record of my MC journey, the source was unlikely: I was looking at a set of subharmonics (I’d typed 4 and 6 into the number boxes and examined the spread of the numbers and the behavior of the mc.phasor~ objects’ separate outputs) when an image of a long-ago tutorial I’d written about using Jitter matrices to visualize a data surface composed of two 2D functions laid out at right angles to one another to form a periodic surface. I was interested in generating control output based on sending a vector across the surface of the data surface (and wrapping that output at the “edges” of the surface.

As I watched the longest phasor outputs from the lowest numbers from the subharmonics, it suddenly occurred to me that there was a connection between the rate at which I traversed the surface and something like the “angle” of traversal in the data surface I'd created in that original tutorial:

If both increments were the same (i.e. if both phasor~ rates for the two functions  were the same) then I was traversing data surface at a 45 degree angle... the same rate of increase for both the X and Y coordinates.

If I modified the rate at which the master phasor~ that drove the X and Y functions individually, I'd be doing the equivalent of traversing the data surface at a different angle defined by the difference in whatever adjustments I'd made to the X and Y rates (using a rate operator, of course): a lower rate for the X function would mean that I traversed the equivalent of my data surface at an angle that was less than 45 degrees, and a lower rate for the Y function would traverse the surface at an angle of greater than 45 degrees.

Further, I realized that I could think of the starting phase of the X or Y function as moving the starting point of the traversal along the X or Y edge of the surface.

And the data itself? It was just a matter of taking the separate X and Y values at their respective traversal rates and averaging them to get the point on the data surface.

Essentially I was doing something I do with LFOs all the time; I’d just never seen it that way before. That’s what you get as a reward for staring at things and listening.

With something resembling growing surprise, I realized that I’d already done most of the heavy lifting for a patch that would let me explore this idea in the previous installment of this tutorial series. It was staring me right in the face.

Here’s the patch from the first MC journey that I started with. It was my first foray into translating my standard LFO patches into MC land:

I started work by using the LFO from that tutorial.

The insides of the MC_LFO.gendsp gen~ patcher will probably be familiar to you by now — with very few changes, its passed from the last LFO tutorial on through part 1 of the MC journey tutorial. The only variant is that we’re using MC to create 8 instances of it.

I have a lot of parameters to keep track of, but here’s where MC saves me a whole lot of time: I can use the mc.combine~ object to gang multiple parameter inputs together in a way that makes sense. I’ve got 2 sets of LFOs, each with their own inputs for waveform selection, phase offset, rate multipliers, and duty cycle. The waveform and duty cycle parameters are such that the same settings will be applied to each group of four LFOs, so I can use a pair of mc.sig~ @chans 4 objects feeding into an mc.combine~ 2 object to set them all.

While there are people who love MC for the ability to create dozens of deviated sine waves at the drop of the hat, my own experience in working with MC has been that its most powerful feature lies in the way that you can radically simplify the visual complexity of your patches.

Let’s put it all together.

I’ve got four pairs of LFOs whose output represents the functions mapped along the X (blue) and Y (purple) axes of my data surface. Let’s look at how I can translate all that complexity into four voices of interconnected and interrelated material.

The mc.gen~ @gen MC_LFO.gendsp @chans 8 object outputs a set of 8 LFOs from the object’s left outlet. In order to get the value of each of the four positions on the surface, I’ll need to grab those LFO outlets in a specific order - LFO 1 and 5, 2 and 6, 3 and 7 and 4 and 8.

To do this, I’ll use one of the MC objects I found while spelunking that’s built for just such a task: the mc.deinterleave object 8. Since each output is a single LFO, all I need to do to output the position on my four data surfaces is to sum and average the individual outlets in groups of 2.

The mc.deinterleave 8 object performs a similar function in letting me sum and average those same 4 pairs of 2 outputs to generate a set of spikes I can use to trigger events. (And yes, I know that those spikes represent both the X and Y edges of the data surface as a single set of trigger outputs, but I liked the variety they provided.)

All of the final note formatting happens here at the very bottom. It’s composed of a gen~ patcher than handles the note/velocity/duration parameter generation, a subpatcher that unravels all that information and formats it for output, and a nifty little scale and mode patch I borrowed from my book book Step by Step: Adventures in Sequencing with Max/MSP to organize the output a  bit further:

When it comes to converting signal-rate input into MIDI note events, there are a squillion ways to do it, and none of them are canonical or “the best." You just start with an idea and tweak it until you’re reasonably satisfied (or satisfied enough to sit with the results and play with the parameters and explore until you get your next idea). Here’s the inside of the gen~ quantize patcher:

There’s nothing too fancy here, really. You’ll notice that I’m using a param object to set the range of the quantized output and then multiplying my inputs by that number, taking the non-decimal part of it (using the floor operator) and latching the result until I get a trigger input from the X or Y edges of my data surface. The latch operator outputs provide the raw materials for scale operators that give me MIDI notes, velocities, and durations. Using scaled input from different latches has the nice side effect of creating quite a bit of variety since the velocity and duration MIDI events are updated at different rates since they come from different latches, and the note is only output when the MIDI note output is sent to the makenote object (which you’ll see in the p unravel subpatcher. 

Here’s what happens to all of these outputs in the p unravel subpatcher:

The subpatcher is simplicity itself: the audio-rate inputs are sampled using snapshot~. I use a Max change object to remove repeated notes. They’re finish by being formatted into four note events using makenote objects and sent on for transposition and scaling.

As I mentioned, I’ve borrowed a patch from my book Step by Step that lets you take MIDI input, increment or decrement the note numbers (which lets you start scales and modes on any starting note), choose from among a set of standard scales and modes, and specify an output key. It’s my go-to tool when I’m working in Equal Temperament. This patch is modified only in that the original in Step by Step was getting a list of note/velocity/duration info, and I’ve stripped things out to only deal with input MIDI note numbers:

Again — there’s no shame in borrowing or repurposing something you already have. It gives you more time to listen to and think about other things.

Once I got things working, it quickly became clear that some combinations worked better than others. I figured that I might benefit from creating a version of my patch intended for exploration — one that allowed me to create presets as I explored. You'll find a copy of it as LFO_datasurface_UI.maxpat.

I fired up the patch, set its output to run my Pianoteq, and settled back for some presetting time (Don't worry. I left plenty of space for you to experiment on your own).

Although I'll end this tutorial here, this is very much a work in progress — I'm thinking again about what the LFO-driven version of data surfing looks like if I fold at the X/Y boundaries instead of wrapping. But hey... I feel pretty confident about MC as a way to visually simplify my patches as I build larger structures, and the future's looking bright. Thanks for reading all this way with me. Onward!

Learn More: See all the articles in this series 

MC_box.png

This installment of the MC tutorial begins with a patching error that inspires an MC-based polyrhythm generator and goes on to exploit MC’s ability to visually simplify daunting patches. We’ll also be exploring the use of LFOs to mimic movement across data surfaces for generative fun.

an-mc-journey-part-3

An MC Journey, Part 3

Welcome to the next part of my MC journey. As I said when I started this trip, it was personal. While I love opening other people’s patches and twiddling the knobs and adjusting the sliders and enjoying the results, I’m usually in search of some sort of inspiration that I can yank sideways into the place where I work.

For this "step along the way" in the MC journey I thought I'd show you another real-world bit of MC patching that takes a number of past projects/tutorials I've created and combines them with what I've learned during this series to make something that I (at least) find interesting and useful.

As I said earlier on, I'm generally not someone who's necessarily moved by MC's ability to control very large numbers of things (although David Zicarelli and Tom Hall's appearance at the Ableton Loop event really impressed me and probably got me intrigued in the first place — you really ought to download the patches and watch the video of the presentation!). But there are places where I've listened to something I've made and thought that perhaps the MC functions would let me explore them on a "slightly larger scale."

One tutorial I've recently written for the Cycling '74 website that comes directly out of my own practice and interest set was borne of my interest in exploring the 4MS Spherical Wavetable Navigator and wondering how I might use gen~ to create something interesting. The resulting tutorial — Winter's Day gen~: The Wavetank — led to the creation of a patch that let me load an 3d grid of waveforms that would be traversed to create an output that morphed interestingly.

It was lovely, but I found myself thinking about what MC might do for me there. How about an MC version of that patch whose pitches and X, Y, and Z traversal values could be independently controlled?

I've also been really interested of late in chaotic attractor equations what I could use in places where a simple LFO wouldn't get me the kind of slowly changing outputs that seemed more to me like "intentionality." I found myself wondering what use I might make of patches like this. Since chaotic attractor patches are heavily dependent on the initialization values (and not all possible values are created equal when it comes to chaotic behavior), any MC versions would start from precisely the same place — I'd need to think about spreading out the results in time or modifying them in some other way.

The value of my careful and pretty personal perusal of MC features (see the previous installments in this series) also gave me a pretty clear idea of how I might approach this. This tutorial is a walkthrough of using MC to realize those ideas.

The morphing wavetank I created in the Winter's Day gen~ tutorial is an idea that’s stuck with me since first I started twiddling dials on the 4MS Spherical Wavetable Modulator Eurorack oscillator and wondering whether I could use gen~ to do something similar.

If you’re interested in the gen~ patching that underlies how it’s done, I’d recommend you take a look back at the original tutorial. Simply put, I created a patch that let me take an audio file composed of a specific number of single-sample waveforms and create a cube (3x3x3 or 4x4x4) I could traverse in 3D using three parameter values to represent a height, width, and depth location within the cube. The resulting outputs was an interpolated result derived from the 27 or 64 waveforms. By modulating the X, Y, and Z parameters, I could produce an interesting morphed output — particularly when driving those parameter values using a set of LFOs.

On reflection, the MC toolkit suggested some really interesting possibilities:

I could use MC to create multiples instances of the morphtank patcher tuned to different frequencies — chords, harmonic multiples, etc.

I could also create some patching that would change the X, Y, and Z inputs for the morphtank patcher at different rates, from different offsets, and so on. That might be cool even if all the morphtanks were running at the same base frequency!

I could use MC tools to spatialize/control those multiple outputs.

In short, it was a perfect candidate for my next MC project.

Creating the MC patch was simple: just add an mc.gen~ @gen morphtank @chans 16 object to my MSP patch. Presto — 16 morphtanks ready to go!

There were a couple of things that I wanted to keep for all 16 instances — the control of the audio files used for the wavetank and its parameters. But when it came to setting the base frequency for each of the 16 morphtank patches, my MC investigations gave me two attractive options:

I could use a harmonic (or subhamonic) 1 <frequency> message connected to an mc.sig~ @chans 16 object to set my instances to frequencies based on the harmonic overtone series.

I could also use the spread messages in combination with an mc.sig~ @chans 16 object to distribute the base frequencies of each instance across a linear frequency range I could specify.

Based on my MC journey, I opted for the second approach, since I realized that the spreadinclusive message that I'd investigated in Part 1 of this series combined with an interesting frequency range could produce some interesting and dense “chords.”

Dealing with the outputs was just as easy, but I need to talk a little about using my chaotic attractor patch first. I’ll come back to that in just a bit.

In my initial explorations of the morphing wavetank, I'd either manually adjusted the three sliders that set the "position" in the cube I wanted to interpolate waveform output from, or I connected up some LFOs with their outputs set to a 0.0 - 4.0 range to animate things automatically.

But the more I listened to the LFO results, the more I thought about what I might use for a little more complex X, Y, and Z parameter input. It might have been the result of my using a single LFO with rate~-driven outputs that modulated the three parameters in cyclic fashion that started me thinking in this direction, or the more simple observation that I don't play faders "like they're LFOs" when I perform.

In any case, that insight got me thinking about using Chaotic equations as modulation sources; they generally appeal to me because there is a kind of trajectory to their outputs that is neither "random" (which I certainly am not) nor periodic in the way that an LFO is.

And as I said, the attractors have been an interest of mine for a long time. The very first Gen patch-a-day feature we did back in 2012 included an example I figured would be perfect for use — a trio of patches that implemented a Navier-Stokes equation in three different gen~ formats (a gen~ operator version, a gen~ expr operator version, and a codeboxed version). You'll find it on day 14 of the Gen patch-a-day series.

It's an old patch, and the intervening time has led me to reconsider how I'd implement it:

Instead of using a train~ object's output to drive the attractor, I've opted instead for a version of the patch that's "always on." With each tick of gen~'s single sample clock, the attractor calculated the next iteration of itself, and then multiplies the result by a very small value that provides the "rate" at which the attractor runs. That small value is then added to the previous one and stored in a history object. The result is a smooth output at a widely variable range. Turning the attractor "off" is a simple matter of setting the dt (change in time) parameter to a value of 0. And the attractor can be restarted at any point by sending the gen~ object the message restart, which resets all the history objects to their initial state.

The other change in my gen~ patcher has to do with improvement to the idea of establishing the limits of the attractor's outputs. You'll notice there's a second gen~ patcher added at the bottom there.

In the past, I’d simply coded up the attractor, turned it on and let it run for a few days, and used whatever the relative maximum and minimum limits I had when I stopped the patch from running (we called it “empirical observation”).

However, when I made the switch to the "add a settable increment’s worth of calculation to the previous value" instead of a train-based approach, it occurred to me that I might see slightly different results at different speeds. Since chaotic attractors not only exhibit “sensitive dependence on initial condition” (i.e. you may get very different results depending on the original settings for the initial parameters), it’s also the case that since chaotic equations iterate based on previous values, a single result that varies considerably from the previous one.

This simple change in my gen~ patcher has introduced me to an interesting problem I’m still thinking about: What’s the best way to establish and work with maximum and minimum values when you don’t know what their range is likely to be? Working with chaotic equations generally threw this into sharp relief for me since the behavior of an attractor calculation — in some cases — seemed to produce different results for maxima and minima depending on the dt for the calculation. If I changed the dt value, I might suddenly find that the relative maxima and minimum values changed. I thought that finding a way to smooth that change over time might be the best solution.

Then I remembered George Lewis talking about just this particular kind of problem with respect to his Voyager program during an interview I did with him earlier this year: He was talking about using “leaky integrators” to manage slow changes in values like this.

Simply put, a leaky integrator is easy to make: Instead of using min and max operators to set and store the relative minimum values forever, you store the next maximum or minimum value when you find it. 

But you also add some patching that slowly lowers the minimum or maximum values over time.  subtracting very small amounts from the minimum value, as well. This slowly changes the amount of the current maximum or minimum by subtraction that’s stored for the next calculation — it “leaks.” Whenever a new high or low value comes along, it sets the maximum or minimum to that new value and it starts leaking again.

I wasn’t sure that I’d have this particular problem at different dt rates, but I thought it’d be best t be cautious, so I mocked up this version for my patch:

Why didn’t I go with that initial min/max > history solution for my leaky integrator? In fact, there’s a very subtle problem with it that didn’t occur to me until my friend Graham Wakefield pointed it out to me; while this solution might work in a situation where the relative maximum and minimum values I’m tracking fall on either size of zero, I’d encounter difficulties in a situation where the relative maximum and minimum both fell above or below zero — the system tends toward zero. The more useful and general case is to create a patch where the leaky integrator’s maximum slowly approaches the minimum in the absence of new maximum values, and vice versa. This makes the patcher more generally useful.

Here’s a version that does just that — the limits now converge on each other by a settable amount (controlled using the param operator and dividing by the current sample rate to get a very small number) to control the rate of “leakage.”

Armed with this new Navier-Stokes gen~  patch, I was ready to start modulating the X, Y, and Z plane traversals for my MC Wavetank.

When it came to setting the rates for the 16 instances, I once again availed myself of the spread messages to set a range for the rate of the attractors' operations.

The nice thing about my Navier-Stokes attractor gen~ patch is that it gives me 5 different outlets. I only need three for modulating the Wavetank’s 3d controls, so I started thinking about what else I might do with two more parameters to play with for my 16-channel Wavetank. It wasn’t too hard, really — I thought I’d use one of the leftover attractor outputs to set the output amplitude for each Wavetank channel, and the other one to pan the result across the stereo field.

All of those operations would require scaling the output range of the Navier-Stokes attractor patch’s output: the first three parameters needed to scale the audio range outputs to the 0.0 – 4.0 value I needed for the Wavetank 3D controls, and parameters four and five both needed to be scaled from bipolar to unipolar ranges. Five well-placed mc.scale~ objects took care of that problem with little muss or fuss. After scaling, the Wavetank inputs went straight into the MC version of the gen~ morphtank patch. Similarly, the amplitude was handled by an mc.*~ object.

Amazingly, I was very nearly done! All I needed was to set the panning for the 16 individual outputs. Having made my way through the MC panning resources available to me in Part 2 of this series, I knew just how the mc.mixdown~ operator handled panning. I went with mc.mixdown~ 2 pancontrolmode 0 object, which spread the panning out across the stereo field by assigning 0.0 - 1.0 values for left-to-right panning. The fifth parameter outputs from the Navier-Stokes patch (scaled for the 0.0 – 1.0 range) set the panning for each of the 16 Wavetank outputs with a single patchcord connection:

My MC patch was ready for prime time. I turned it on, and... Wow. <Insert some serious tweak time here>

Before I go, I wanted to mention one more little personal tweak that produced some interesting results. As you might imagine, each of the chaotic attractor mc.gen~ patches outputs exactly the same values at the same rates (even though each instance runs at a different rate, the 5 outputs are all clocked the same). I started thinking that a further way to introduce some variety would be to consider "rotating" the X, Y, and Z outputs being sent to the MC version of my morphtank. Since each of the 16 instances would be clocked differently, rotating the X, Y, and Z inputs would mean that each one of them would update at different rates.

So I started researching how I might consider implementing a rotation for those outputs. As I always do, I check the in-app Max help first. There was some discussion about using an mc.matrix~ object, but that looked pretty daunting (and I'm not ashamed to say it). What I did find in the "Search the Forum" results was that Timo Hoogland had produced a suite of MC utilities (available at no cost, although he would appreciate you filling the tip jar, I'm sure) that include an abstraction that does just that. You might want to try it (I obviously can't give you a copy of someone else's work, but here's how I added it the main patch):

image2.png

For this edition of the MC journey, I’m going to combine some longstanding interests of mine (using materials from earlier tutorials) together with the MC tricks I’ve acquired during my journey to create a rich, undulating bed of morphing MC drone. 

an-mc-journey-part-4

An MC Journey, Part 4

I’d like to start this series of tutorials with a confession: I work slowly.

Knowing that about me probably explains a lot of things, from the rate at which the tutorials I write appear to the rate at which I release recordings, all the way to how long my current MSP performance rig has been around (hint: it’s measured in years). That doesn’t mean that nothing has changed, of course — merely that I’m one of those slow preparation/fast execution people. When I’m experimenting with implementing new algorithms, I’ll set something up, turn it on, and let it run for a looooong time, listening and tweaking along the way. Similarly, the arrival of new software features — even features in Max — don’t send me down the rabbit hole right away; I tend to try to work my way through them at my leisure, a little bit at a time, until I figure out what the little bits are doing and then imagine where they might fit the way I work and think about things or until I notice something unexpected and start the (slow) process of integrating that into my practice.

The arrival of Max’s MC features has been a game-changer for a lot of Max users, who wept with joy at the ability to use things like the deviate message to retune enormous banks of sine waves or patch large and complex audio processes without the previous "subway-map-from-Hades" riot of patchcord connections. 

But while the world has filled with new swarms and clouds, there are still people out where who’ve found it a bit daunting, or wondered how they’d begin to make sense of it. (Witness all the beginner videos out there, in case you doubt me.) I’d like to begin a small set of tutorials in a different way – to chart my own path into using some of Max’s MC features, one small piece at a time. If you’re familiar with the tutorials I’ve written, you’re going to recognize the raw materials pretty quickly – they’re things I’ve created earlier (and, occasionally, modified just a bit for these tutorials for reasons that will become apparent). While it’s possible that my way of working doesn’t match your own, I hope that the through-line of investigation remains clear, and that you can find something useful and (I hope) inspiring. Let’s get started.

Longtime Cycling ’74 website readers probably know one thing about me for certain: I love low frequency oscillators (LFOs), and I’ve got the tutorial series out there to prove it. While the LFO’s service in audio as a modulation source is ubiquitous and great, I personally tend to approach them as a slightly more general source for generating and organizing variety. I use them to rescue myself from situation in which abandoning some part of my Max patching to randomness seems or feels wrong because, well, I’m not random.

So you’d be right in imagining that the first time I saw a video tutorial about using the deviate message to retune a huge bank of sine waves, I started wondering about going low instead of going high.

As you know from my LFO tutorial series, I started by creating a simple LFO patch, and then began to investigate what I could do by creating multiple instances of that patch and then modifying them individually and summing/averaging the results to create more complex control structures. When Gen came along and I’d decided to embracing using it, I realized that porting my LFOs to gen~ was really a pretty easy task, and that gen~ allowed me to realize a good deal of efficiency by “ganging” those multiple summer/averaged LFO networks into a single gen~ object.

So I figured that that’s where I’d start: take a gen~ LFO patch and move it into the MC world and see what I could do with MC’s features that would match up with my working methods.

It's not hard to figure out that one of the great features of MC involves the ability to create a wrapper around multiple Max objects that lets you address each instance individually — especially useful when you use some specialized MC features to set and modify those individual instances from a single source. So I decided to take a version of my standard gen~-based LFO and to create a special version of it for use in the MC world (You'll find this patch - single_channelLFO.maxpat -  in the folder of patches I've included):

If you're familiar with my basic gen~ LFO, there aren't a lot of surprises for this as a starting point. The main difference is that I've converted the contents of the gen~ object so that each of the parameters is now a signal input rather than the message-based Gen param operator approach I often use. Here's the contents of the basic_MC_LFO.gendsp file I've saved as a separate .gendsp patch and loaded into the gen~ object using the @gen <filename> attribute:

I have made a few revisions to the gen~ LFO here. First, I'm using the @default attributes for the in operators to set up my gen~ patcher so that I've got a standard set of starting parameter values for my LFO:

The frequency of the phasor operator (@default 1 Hz.) that drives everything else

I've added the ability to set the phase of the individual phasor operator (@default 0.) with a floating-point number value between 0. and 1.0. Not sure why I didn't add this feature before, but I figured that individual phase controls might prove useful (and they will... trust me).

Each phasor operator uses a rate operator (@default 1.0) to scale the phasor operator's output for nice long rates of change

A duty cycle setting (default 50%) for square-wave output

A waveform select option via the selector operator.

The output from the phasor operator (adjusted for phase and output-scaled as needed) is used to generate six different output waveforms. The triangle operator does most of the heavy lifting here, using argument settings to output positive and negative-going ramps or triangle waveforms, with the cycle operator (which uses the @index phase attribute to transform the phasor operator's ramp output to a sine wave and a latch operator-driven noise source (triggered by the end of the master phasor's 0. - 1.0 cycle) that produces random outputs.

I also decided to add an output that indicated the point at which the phase-adjusted and output-scaled phasor wrapped to 0. as a second output. I've found over time that I use that feature a lot - usually adding a little MSP patching to generate bang messages from the spike.

Moving this patch into the MC world requires nothing more than loading the MC_LFO.gendsp file into the MC version of the MSP gen~ object (mc.gen~) and specifying the number of instances we want to work with using the @chans attribute. In the interests of clarity (and my own predilection for quartets), I'm going to create a patch with 4 different LFOs: mc.gen~ @gen MC_LFO.gendsp @chans 4.

That now means that each individual inlet in the mc.gen~ object now addresses 4 independent inputs, so I'm going to need to add a way to address each of the four instances. It's MC to the rescue once again by means of the mc.sig~ @chans 4 object. In practice, you'll find that a good deal of the work you do in MC involves substituting the MSP objects you already work with with their MC variants. In some cases, some Max UI objects will automatically adjust to the number of output channels they receive. The scope~ object is just such an example of that — connecting scope~ objects to the waveform and trigger outputs automatically convert to multichannel displays (you can click on the dots at the bottom of the display to see which instance you're viewing. They all look the same, at the moment because they're all set to the same default values).

There are a number of ways to send data to the mc.sig~ objects, but I'm going to go with a really simple method, adding an mc.input 4 object to each of the five mc.sig~ @chans 4 objects. After that, providing control for each parameter of each instance of the LFO is just a matter of adding some number boxes to the patch. Here's the result (the multichannel_LFO1.maxpat patcher file_:

Using MC to created a multichannel version of the basic LFO has the additional advantage of simplifying the internals of a any patch that outputs multiple instances of something - you just don't need the mass of internal param and setparam operator-based logic you'd usually rely on (e.g. needing parameters like phase1, phase2, and so on). Even though I am working with 4 independent instances of my LFO, I didn't have to modify the internals of my basic_MC_LFO.gendsp patch at all.

Once I had that hooked up, I started experimenting with changing input values. Setting different phasor operator rates immediately produced changes to the multichannel displays, so I could see that was happening and could select each instance's display separately.

Finally, summing and averaging these multiple LFO outputs to produce exotic and interesting waveforms involves nothing more than adding an mc.mixdown~ 1 object and multiplying the result by .25 to scale the output into the standard -1.0 - 1.0 output range. In the case of the trigger outputs, we don't need to scale at all - one mc.mixdown~ 1 object does the trick. And, as long as I've got four separate triggers based on the phase-adjusted and scaled phasor operators, I might as well pull them out to use separately. How do I unpacke 'em? Yep, that's right - an mc.unpack~ 4 object. You can see the results in the multichannel_MIDI.maxpat file.

After I got my patch to the point where I could access all the parameters, I thought I'd check some of the interesting ways to interact with MC objects that were available to me. I'd certainly seen and heard about the deviate message, but was wondering about what else there might be. It was time to click on the magnifying glass in my patcher window to fire up Max's in-app search. Sure enough, I found what I was looking for in the Generating a Range of Values for All Wrapper Instances section of the MC documentation. The idea of distributing parameters across a specified range was much more compelling to me than deviation, so I thought I'd go with that. 

I'd found what I was looking for but um... I wasn't quite sure that I understood it. So I went for my usual Plan B when consulting documentation: Create a Max patch that lets you explore the thing you're having trouble making sense of, and play with it until you do. Since I was dealing with numbers distributed over a range. I created the spreading.maxpat patch in the distribution to do just that. I could input specific values in the range of 0. - 1.0 or scroll the integer number box, and watch how several variations of the spread messages behaved, and - most importantly, seem them next to one another (Sometimes, a value didn't do anything and, once I got the hang of it, I could easily see why). Here's the patch in action:

There were two features of this work that surprised me a little. First, I think I would prefer to use different varieties of the spread message for different functions. Here are some examples:

For phase offsets, I want the lower bound clamped to zero (no phase adjustment) and to keep the fourth value below 1.0, since that's really the same thing as a phase of zero). 


I'd like to do my range setting by specifying the upper and lower bound when it comes to multipliers for my phasor operators


Duty cycles for square waves should never use zero or one for values. 

I'll use different flavors of the spread message for each situation — choose the tool that fits the task.

The second insight is something I'll save for later. It knocked my work completely sideways and sent me right down the rabbit hole. But more on that later....

For phase offsets, I want the lower bound clamped to zero (no phase adjustment) and to keep the fourth value below 1.0, since that's really the same thing as a phase of zero).   

I'd like to do my range setting by specifying the upper and lower bound when it comes to multipliers for my phasor operators  

I'll use different flavors of the spread message for each situation — choose the tool that fits the task.The second insight is something I'll save for later. It knocked my work completely sideways and sent me right down the rabbit hole. But more on that later....

Hey - I think I've won the prize for going the longest in an MC tutorial without making any noise! But that's okay with me - I'm trying to get things sorted out in terms of UI/parameter control and figuring out the spread messages.. It's time to hook up something to make a little noise. I think I'll use this as the basis for a step sequencer (those are also close to my heart, as you may have noticed or read). Here's how it'll work:

I've got four independent LFO waveforms, each of which has its own trigger output, as well. I'm going to sum and average all four waveforms to created the waveform to sample to derive MIDI note numbers.  

I've got four independent trigger outputs, as well. I'm going to create a way to use one or more of them to serve as the latch for waveform sampling. I'd like to be able to arbitrarily apply any trigger (or group of them) to the latching/sampling, and to create a four-output version for my MC step sequencer.t  

I think I'd like to be able to add some sync to my individual LFO outputs, while I'm at it. That might require a little thought, but it's a feature I want.

There are a lot of places I could go with this basic design from there - grab the individual waveforms and use them to drive filters, use the summed exotic audio output for pitch for an oscillator, and so on. But I'm going to keep it simple: 

I'll add some very simple sample/hold-based parameter acquisition to get me the component parts for a MIDI note message (pitch/velocity/duration),  

Take my MIDI message patching and multiply that by four (one voice in honor of each of the LFOs) to get a four-voice patch  

I'm going to borrow a little scale-mapping patching from a random grid sequencer Max for Live device I wrote a tutorial on a while back to add some scale/modal rectitude to the proceedings.

And I do need to add that synchronization to the patch while I'm at it.

As things stand, I've got some really interesting summed waveform action -  the output of the mc.mixdown~ 1 and *~ .25 object pair. I've also got four independent triggers (one for each phase-adjusted and scaled phasor operator in the MC_LFO.gendsp patch. The nice feature of my exceptionally busy summed waveform is that all I have to do to get very different MIDI message results is to sample the waveform at the slower rates of the phasor operators - as the triggers cluster or overlap, I'll be grabbing the same note or one nearby. Widely spaced phasor speeds will sample from the same material at wide intervals. And, should I desire it, the results can be made periodic by judicious sets of parameters for rate, phase, and multiplier (especially in situations where I'm using the same waveform in all four sets of LFOs. After some trial and error, this patch falls well  into the kind of patching I generally enjoy — something whose adjustable variety implies pattern and intention rather than randomness (and your personal mileage may vary here, but on the bright side, this can be coaxed into staggering randomness with only a little effort).

Assembling the MIDI note messages is handled by the ez-map patcher. Each instance of the subpatcher grabs its input from some combination of three of the four audio outlets from the mc.unpack~ 4 object and from the summed waveform to sample. Here's a look at what's under the hood:

It's a straight-ahead piece of work: three sah~ MSP objects take the summed waveform as input and grab the triggers sent into inlets 2, 3, and 4. Each spike grabs a sample of the summed waveform and scales it for use as a MIDI note number (I'm using a narrow range of notes 24 to 48 and then transposing and scale-mapping that value later on. The audio-rate result is then converted to even data with a snapshot~ 20 object and a change object that filters out repeating triggers.

You'll notice there are two additional objects for the first sample-and-hold patching: I decided as I developed the patch that I found total chromaticism kind of boring, so I thought I might do some scale mapping to use different scales and modes (and my own non-western tunings, although I really don't need anything special to do that, since the tuning tables are done via lookup in another MSP patch).

A while back, I wrote a tutorial that used noise surfaces in Jitter to generate synth controls. In that tutorial, I included some patching to make scale mapping a little easier (you'll find it used in my book Step by Step, as well). It's perfect for this patch, so I've taken the liberty of borrowing it and using it here.

Those two extra objects are all I need to use the patching I've cut from the noise tutorial patch - all it does is to increment a lookup table index (the table object in Max counts from one instead of the more usual zero), and use that index to lookup a numerical offset to the pitches we've sampled stored in a table object.

Note: If you're interested in working through the scale mapper patch, I'd suggest firing up and checking out Noise Tutorial 1: Riding Tandem With The Random. You'll find the scale mapping stuff described in the section Scale mapping for fun and profit.

The rest of the MIDI patching is a question of collecting and routing the three outputs from the ez-map subpatcher. I added some octave offsets to add variety to the four voice, and decided that I liked using the buddy object to synchronize the different pitch, velocity, and duration outlets (I don't really need it, but decided that I liked the results when working with extreme ranges. Like I said, I patch and then tweak and listen a bunch).

The only other thing I needed was some reset logic. That involved adding a new inlet to the basic_MC_LFO.gendsp patcher that connected the right inlet of the only phasor operator in our patch (I love how easy loading multiple instances of gen~ patches using mc.gen~ - it makes keeping track of things so much simpler). I renamed the patch MC_LFO.gendsp because that's the version I'll be using from here on out, and loaded that new version into the mc.gen~ object. Sending a non-zero value to all four instances is done by using an mc.target 0 object (zero meaning "send the input to all instances") and another mc.sig~ @chans 4 object to the main patch. Presto - reset!

Here's what it looks like with everything in place in the multichannel_format.maxpat file. I added some pattr objects/a preset object/a pattrstorage bit of preset prep, and the easy-peasy output mapping. It sounds pretty good for a bunch of MC LFOs, I think.

That's it for now. Next time out, I'm going to show you what it was during this patchfest that was the mysterious "other thing" that caught my attention. The resulting journey down the rabbit hole will be the starting point for the next excursion. Stay tuned....

image1.png

The arrival of Max’s MC features has been a game-changer for a lot of Max users. This short series of MC tutorials will chart my own path into MC, learning what it did that would fit with my workflow. It borrows from earlier work of mine, and I hope that the through-line of investigation remains clear and that you can find something useful and (I hope) inspiring.

an-mc-journey-part-1

An MC Journey, Part 1

Welcome to the second part of a short tutorial series that’s something of a departure for me in that it’s personal and idiosyncratic. As a Max user, I expect that, like me, you make your way through the Package Manager or follow up on Forum postings or haunt the Projects - or just type what you’re interested in into the Search on any patcher window to see what comes up every once in a while - and then you start spelunking. I know that lots of people do it because the Forum is full of people who are obviously in the midst of just that; and when you think of it, the Projects section of the website and the Package Manager are full of people sharing what they found while they were out working in the Patch Pile.

So when someone asked me about writing an MC tutorial, I thought I might try something a little different: I’d try to put together a little homage to the many Max users out there who’ve taken some new Max feature of set of tools and tried to figure out what to do with them that fit their own interests. There’s an element of risk in this — namely, that there’ll be readers who wonder why on earth something I’m doing would matter at all. But we’re all like that, aren’t we?

In my last toe-in-the-water venture into MC-land, I started with something I use all the time – Low Frequency Oscillators (LFOs), and quickly discovered that a lot of the extra messaging and logic necessary to control them could be really easily replaced using MC. It was a great first step, and I’m using the results regularly now.

While I was hunting around for ways to generate some variety in a less stochastic way than using the deviate message, I happened across a trio of messages I could use in an MC patch to spread a set of values out between a low and a high range: spread, spreadinclusive, and spreadexclusive.

To get a feel for how the messages worked, I set up a simple Max patch that let me enter a range and compare the results for several variations of the spread messages in one place at one time. Here’s the spreading.maxpat patch in action (I’ve included it in the tutorial patches this time out so you don’t need to hunt for it or download it again):

As I stared at the different outputs, a little light went on, and my trip down this tutorial’s rabbit hole started in earnest: I suddenly realized that some of those numbers looked awfully familiar somehow. Then I saw it —those values could be used to specify oscillator frequencies!

My artistic practice for many years has involved electronic work that combines some features of central Javanese gamelan music with non-equal-tempered tunings and timbres. That means that I work with scales whose notes are not in the same positions as you’d find on a regular keyboard. As a practical matter, I started using something called Just Intonation to define what those scales were. Simply put, Just Intonation lays out pitches in a scale by using small whole number ratios rather than the twelfth root of 2 as a frequency multiplier that your regular equally tempered piano uses. Another big part of the reason that Just Intonation was an appealing choice also had to do with the fact that frequency ratios are the means by which you can control the pitch of sidebands in a frequency-modulated oscillator. Long experience in both these areas is probably the reason I saw those lists of spread numerical values and thought “chords!”

The MC patch I was staring at could be repurposed as an MC patch that would output audio whose intervallic structure could be defined and changed on the fly.

If you’re not really familiar with things like Just Intonation and tuning, let’s start with a really simple patch (00_consonance_sweep). 

Open the patch, click on the ezdac~ object, click on the red box, and listen. You’ll hear two oscillators that slowly go out of tune with each other so that one of them slowly sweeps upward until it’s an octave higher in pitch. Along with way, you’ll hear the two oscillators beating against each other, and you’ll also notice that there will be points when the beating quiets or when you momentarily recognize intervals you know. It turns out there’s a pattern to that sliding or alignment between the two pitches (and you might try them using waveforms other than sine waves, while you’re at it), and there's a name for what you're hearing. Psychacousticians such as Ernst Terhardt refer to it as dyadic harmonic entropy - an experimentally-derived map of how listeners perceive the relative consonance or dissonance of two notes sounding together. 

There's unison on the left, and a pair of pitches an octave apart on the right. Those bumps in between the highly consonant and ending points refer to pitch ratios that we hear as consonant. The big dip toward the middle is a pitch ratio of 2 to 3 (which is a perfect fifth). You'll find some other bumps you'll probably recognize: 3 to 4 (a perfect fourth), 4 to 5 (a perfect third) and 5 to 6 (a minor third). The deeper the "bump," the more consonant the interval seems.

But I'd actually heard about that a very long time ago, and from an unlikely place - from Donald Duck. This happened a long time before I ever knew what Equal Temperament was, let alone what the relationship between whole number ratios and pitches were. Go on - scroll ahead to 2:30 or so in this video and enjoy!


And what you just listened through in that last MSP patch has one other interesting property: the perception of consonance is also related to the harmonic overtone series. The perception of an interval's consonance varies according to the number of overtones coincide with each other. 

Here's an example that shows how the harmonic series of two notes a perfect fifth apart (i.e. in a frequency relation of 2 to 3) versus two notes a major whole-tone apart have overlapping harmonics (shown in blue).

So I decided to use these ideas to create a set of drones where the harmonic content of an individual "note" was related to the frequencies in my "chords" using MC.

Numbers, Fractions, and Musical Intervals

When I first started working with non-12-tone-equal-temperament (or !12tET, as it's sometimes called), it was difficult to remember my intervals. I knew that 1:1 was unison, and 2:3 was a perfect fifth above that, and 1:2 was an octave, but the rest of pretty tough to remember. And when it came to harmonics, the process of multiplying frequencies and then folding the result so that they fell into the compass of a single octave (instead of being 16 octaves above the original note) was quite a lot of work. 

Happily, composer and microtonal theorist Kyle Gann came to my rescue with his helpful Anatomy of an Octave web page, chock-full of useful descriptions of ratios and the names we usually associate with them. That work, in turn, is based on Alain Danielou's encyclopedic Comparative Table of Musical Intervals, which has been out of print for quite a while. (You can find a link to a PDF here, should you be interested.)

I took his table as my starting place, and made a few judicious changes:

I removed the references to Equal temperament from the table.

I'm working with decimal values as output from the spread, spreadinclusive and spreadexclusive messages, so I've calculated and included the floating-point decimal equivalents of each ratio in the table listing.

The document Interval_Aid.pdf contains the fruit of my labors, and I've included a copy of it with the software download. I hope you find it useful.

Armed with these tools, I decided to redo my original spreading.maxpat patch so that I had a single output source for all of the spread message variants:

Exploring the spread message results involved little more than inputting the upper and lower range and consulting my Interval_Aid document. 

In this case, the result was a chord consisting of a root, a perfect major third, a perfect fifth, and a perfect minor seventh. Not too bad!

For upper limits higher than 2.0, it's just a matter of halving the results until they fall within the 0. - 1.0 range and then consulting the table.

This gives us a chord consisting of a root, a perfect minor seventh, a perfect major third above that, and an overtone 6th (3.25 * .5 to check the interval). It's a lot easier to listen than to look up stuff, so I wired together a little bit of MC to generate a separate waveform output for each of those frequency ratios (with a selectable frequency for the root tone, of course). The result of my spread message modifications and the MC necessary to generate the four outputs is straight-ahead basic MC that you've seen in any number of online/video tutorials (and which you'll recognize from techniques in the first installment of this tutorial). Here's the result: the 01_make_me_a_chord.maxpat file.

Remember how I mentioned the term "rabbit hole?" This is it, in a nutshell — lots of time exploring spreads and figuring out what intervals I was actually hearing, adjusting the upper limit so that the third value showed up in the second position and listening to that, and so on... .

The world provides us with interesting examples of musical practice where an exotic tuning can be partially explained by looking carefully at the timbre of the instrument playing the scale. In his book Tuning, Timbre, Spectrum, Scale, William Sethares approaches the idea of sensory consonance from a slightly different angle: what if we base the notes in our scale on the timbre of an instrument to maximize the harmonic overlap?

For me, that was an obvious next step, and one that wasn't all that difficult to achieve. Here's what I needed:

Grab each of the four values that resulted from the spread

Use those four values to set the "offset from root" frequency for each note — that way, the notes in the "chord" precisely match the position of the four "partials" of the root note

Output the 4 results as stereo audio, and combine those signals together

After my LFO adventure described in part 1 of this tutorial series, making that happen was just a question of copying my basic patch 4 times and adding a few judicious MC versions of MSP objects I knew well:

mc.unpack~ 4 to give me the frequency multipliers for each note in the "chord" 

an mc.*~ object for each of the unpacked note values to use alongside my base frequency multiplier

a little mixdown at the end with a quartet of mc.mixdown~ 2 objects to spread my partials to stereo

a final mc.combine~ 4 object to game them for a final mx.mixdown~ 2 for stereo mixdown:

What's the result of linking the collection of spread pitch values to the base frequency of each of the four stereo note outputs? Let's take a look at the frequency outputs for each of the four "partials" of the four notes in our "chord." In this really simple case we'll use 1. and 4. for the spread values, and use spreadinclusive $1 $2 to set the output range, and set a base (root) frequency value to 100. Hz.

This is about the simplest case you can imagine, but you'll already see what's going on here: Since frequency is exponential (each doubling of frequency is an octave), you'll notice a proliferation of octaves from the 100 Hz. base, shown in black, spread over 5 octaves. The notes in blue divide down to ratios of 2:3, which also gives us 3 octaves of pitches a perfect fifth up from the base frequency value.

Let's look at slightly more exotic case. We'll use 1. and 2. for the spread values, and use spreadinclusive $1 $2 to set the output range, and set a base (root) frequency value to 100. Hz.

This time, things are a little denser and stranger. We've still got three octaves of our base pitch of 100., but the spread has given us two non-octave intervals, which you can see in the first column: 1.3333, which is a perfect 4th (show in blue, along with its octave variants), and 166.67 (shown in red with its octave variants) which is a major 6th in Just Intonation (3:5).  If you're a serious Just Intonation fan, you'll also notice the minor seconds (10:11 or 222.22 as shown here) and a minor seventh in there, too (9:16 or 177.78).

Setting things up this way pretty much guarantees that there will be pitches that emerge from the mass of notes because the partial structure and the scale notes themselves are related.

While it might be interesting to look at the numbers, that's not what I use the patch for.

I learn by going where to go. No, really.

I choose two values and a spread variation and then grab one floating-point number box or the other and then scroll it until I can hear something emerge from the sprawl of frequencies. Occasionally, I use the line object to set up a sequence of slow transitions from one of those discovered emergences to another and lay them atop a drone bed derived from the same base frequency, too. It's been a surprising source of raw material that I would never have happened upon without MC. 

I've been using the mc.mixdown~ object all along to handle transformations from one channel grouping to another (as well as handling the final step of folding down to a stereo output). In the course of reading up on the object, I happened upon the description of how I could use this handy object for panning as well as mixdown — you can read up on it in the Mixing and Panning in MC section of the documentation. The implementation is really well thought-out and varied enough that I found one mode that made intuitive sense to me right away:  Mode 0 (0.- 1. - circular panning).

Simply put, you set pan position as a value between 0. and 1.0 that represents an even-power pan within a circular configuration of channels spread evenly across that range.  Here's what a four-channel mono configuration looks like: 

That looked like just the thing, with one minor variation: I had four stereo channels to spread across the panning field rather than four mono channels. While I could certainly use position C in the example for the right channel of my first stereo pair whose location was at point A, I thought it might be more interesting to be able to locate the starting point for all eight signals and individually and then use a single source to rotate them all. (I may decide to go with separate rates for each channel someday, but what I've got now works just fine for me.)

Given the complexity of what was being managed, the setup for circular panning was surprisingly simple: send a list that identifies the pan positions for each channel to be mixed down to the right inlet of the mc.mixdown~ object. That's it. Want to move things around? Just add some patching that modifies those positions in the list, and you're done.

Once again, the MC extensions of standard MSP objects I use all the time saved the day. I set up some patching in MC style to 

Search Results