My Favorite Object: rate~


    It’s my turn to talk about “my favorite Max object,” and there’s a problem. Two problems, really. First, I’m not sure I have a single favorite object – when I look at my patches over the years, it’s true that I have tended to stick with a few objects as the go-to for solutions (trigger, svf~, the multislider, the matrixctrl object), but those are my bros - the noisy, hip, high visibility d00dz in my Rat Pack. What if my real favorite is quiet and humble rather than something that graces every UI I make? Over the months, my colleagues have also weighed in with articles about objects that I probably would have written about myself – so you don’t need to hear about them again. I’ve also been thinking recently that perhaps my favorite max objects come in pairs rather than being solo performers - using a >=~ .5 and edge~ object pair to convert phasor~ output to a nice bang message, for example. It was the contemplation of that very pair that led me to the subject of this “Favorite Object” post – a humble MSP object that can do nothing by itself, but is capable of great things in the right company: rate~.
    The rate~ object is mute as a stone when not in the presence of a signal input in the range of 0. – 1.0. But feed it the output of a phasor~ object, and the rate~ object will helpfully time-scale the output of your phasor~ by an amount set by an argument, numbers or signal-rate input. A rate~ object with an argument of 2 will produce a ramp from 0. To 1.0 at half the rate of time as the original ramp. Similarly, A rate~ object with an argument of .5 will produce a ramp from 0. To 1.0 at twice the rate of time as the original ramp.
    The following patch demonstrates a classic example of the rate~ object at work – creating the kind of clock multipliers and dividers you or your friends have in your analog rack. To translate the output of a phasor~ or rate~ object, all we need to do is add a pair of Max objects: >=~ 0.5 and edge~. Used together, they’ll generate a bang message at the start of the ramp (from the phasor~ or the rate~ objects).
    You can see how the rate~ object makes things simple – feed an integer (for clock multiplication) or its reciprocal (derived using the !/ object) to a rate~ object and you can derive multiple useful bang messages from a single phasor~ input. Although the rate~ object is used with MSP objects that are ITM-aware (e.g. the master phasor~, the rate~ object itself is not. That’s no problem at if you’re interested in taking phasor~ rates that correspond to notes (2n 4nd, 16nt, etc.) and using rate~ to act as a multiplier, but it may also be useful to use ITM values to set the rate~ object. To do that, we use the MSP translate object – the Swiss Army Knife of MSP format conversion. A quick way to do this is to translate a note value to its equivalent in Hz. At the current tempo, and then take the reciprocal of that number as the argument to the rate~ object.
    You can use the output of the rate~ object anywhere the output of a phasor~ object can be used as signal-rate input (groove~ and 2d.wave~ come to mind as interesting possibilities right away), but I’d like to show you a few things that I use the rate~ object for besides those: Using the rate~ object as a complex control signal generator. I think I happened on the practice of doing this entirely by accident. I happened to hook up the output of a phasor~ object to the right inlet of the rate~ object (which accepts signal-rate values as inputs in addition to the ints and floats I’d been using). The results were amazing – the degree to which the output of my phasor~ was being scaled was being changed on the fly, which made the input phasor~ output kind of crumple up at the start.
    It was cool. And – of course – I could use tempo-locked phasor~ objects as input for predictably crumpled output values. I could also use the output of my phasor~ to both provide input to the rate~ object and as a signal input to the rate~ object at the same time. I could use my phasor~ to control the rate~ object’s scaling input, and then add another rate~ object to that initial phasor~ ramp….
    The rest, as they say, is history (or at least a whole evening of fun and experimentation). I had a really interesting way of producing time-varying ramp outputs I could easily control (and whose output I could again scale with the addition of another rate~ object. But then I remembered my trusty click generating <=~/edge~ pair. The result? Interesting expanding and contracting trigger sources.
    Further Mischief Mindful of Brian Eno’s famous Oblique Strategy (Honor thy error as a hidden intention), I thought that there might be other interesting possible unorthodox connections worth exploration with my now not-so-humble rate~ object. The next one seems totally obvious in retrospect: If the rate~ object expects to work with a ramp in the range of 0. to 1.0, what would happen if I fed it something other than a linear ramp? I quickly cobbled together a little patcher that took phasor~ input to generate the same standard waveforms I used in my LFO patches, and then used a scale~ -1. 1. 0. 1. object to to rescale the outputs into the 0. – 1. Range, and fed the outputs into a rate~ object. The results were pretty promising. There was some wave folding going on, and using a nice high number for the rate~ object would spread the time out so that I was generating interesting control curves:
    I figured I ought to do a little experimenting with ITM-aware values, and so I did a little exploratory patching – I set up a nice ITM-aware phasor~ with rate~-based scaling on its output, and added the ITM variation for choosing the scaling rate of the rate~ object at signal rate. It turns out that the default behavior of the object is a mode – the lock mode. Up until now, I’d been using a vanilla rate~ object, where any change to rate~ re-syncs its ramp's start to the master phasor~ object's start. Since I was messing around earlier with changing the rate on the fly, I was wondering about what would happen when the original and rate~ object outputs got out of sync. I had my answer. I looks like the cycle mode does the resync by looking at the master phasor~ object’s output whenever the rate~ object finishes it’s work. To investigate a little more, I set up a pair of outputs with different modes, and ran them from the same inputs. The results were pretty astounding:
    Fast forward several hours of my listening to scraping noises and generally having a great time. And finally, I realized that I could create a nice patcher that let me select a waveform (and a multiplier for it, thanks to the rate~ object) at ITM rates and use that as the input to both the master phasor~ and the rate~ object independently.
    The possibilities for where to use this are, um… pretty good, as we say in the American Midwest. Just for fun, I’ve hooked that last patch up to an MSP patch that pumps white noise through an svf~ object where all I’m doing is using my wonderfully crumply rate~ object output to control filter cutoffs and resonance (at independent but synchronized rates, thanks to… yeah, that’s right – another pair of rate~ objects.
    I hope this gives you an idea of why I’m a big fan of the rate~ object. Happy patching!
    Check out the entire "My Favorite Object" series: bucket, stutter~, jstrigger, multislider, plot~, trigger, rate~, jit.slide, curve~, jit.gl.mesh, button, jit.gl.pix.

    • May 17 2017 | 4:17 pm
      Thanks for this! I'm working on a virtual modular in Max and had wondered how I'd do clock dividers/multipliers.
    • Nov 16 2017 | 10:30 am
      Intriguing! Thanks for sharing all this work.
    • Mar 06 2018 | 7:11 pm
      Hmm. Does this still work? in Max 8 Win 10 64 I'm not seeing the bangs fire in any of the demos