Gregory Taylor

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 

 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 (

 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 

 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: 

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 

 object will helpfully time-scale the output of your 

 by an amount set by an argument, numbers or signal-rate input. A 

 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 

 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.

image.png

The following patch demonstrates a classic example of the 

 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: 

. Used together, they’ll generate a bang message at the start of the ramp (from the phasor~ or the rate~ objects).

 object makes things simple – feed an integer (for clock multiplication) or its reciprocal (derived using the 

 object and you can derive multiple useful bang messages from a single 

 object is used with MSP objects that are ITM-aware (e.g. the master 

 object itself is not. That’s no problem at if you’re interested in taking 

 rates that correspond to notes (2n 4nd, 16nt, etc.) and using 

 to act as a multiplier, but it may also be useful to use ITM values to set the 

 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 

 object can be used as signal-rate input (

 come to mind as interesting possibilities right away), but I’d like to show you a few things that I use the 

 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 

 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 

 was being scaled was being changed on the fly, which made the input 

It was cool. And – of course – I could use tempo-locked 

 objects as input for predictably crumpled output values. I could also use the output of my 

 object at the same time. I could use my 

 object’s scaling input, and then add another 

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 

 object. But then I remembered my trusty click generating 

 pair. The result? Interesting expanding and contracting trigger sources.

 (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 

The next one seems totally obvious in retrospect: If the 

 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 

 input to generate the same standard waveforms I used in my LFO patches, and then used a 

 object to to rescale the outputs into the 0. – 1. Range, and fed the outputs into a 

 object. The results were pretty promising. There was some wave folding going on, and using a nice high number for the 

 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 

-based scaling on its output, and added the ITM variation for choosing the scaling rate of the 

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 

 re-syncs its ramp's start to the master 

 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 

 object outputs got out of sync. I had my answer. I looks like the cycle mode does the resync by looking at the master 

 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 

 object) at ITM rates and use that as the input to both the master 

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 

 object where all I’m doing is using my wonderfully crumply 

 object output to control filter cutoffs and resonance (at independent but synchronized rates, thanks to… yeah, that’s right – another pair of 

I hope this gives you an idea of why I’m a big fan of the 

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~.

Download the patch used in this tutorial.

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!

Learn More: See all the articles in this series 


zip-and-unzip.jpg

While many of you may be familiar with the rate~ object when paired with the MSP phasor~ object for scaling generated ramp outputs, there is a wealth of hidden wonderfulness that I’d like to show you.

my-favorite-object-rate~

Thanks for this! I'm working on a virtual modular in Max and had wondered how I'd do clock dividers/multipliers.

Intriguing! Thanks for sharing all this work.

Hmm. Does this still work? in Max 8 Win 10 64 I'm not seeing the bangs fire in any of the demos

Hmm. Does this still work?  in Max 8 Win 10 64 I'm not seeing the bangs fire in any of the demos

I have a really important issue regarding sync between phasor and rate..

Every time I reset the phasor's phase to 0 and the rate's (@sync lock) multiplier is different then 1, the rate's phase doesn't start from 0.. I was relying on this to trigger events and start from the beginning always the same way every time I wanted.

For the problem above I solved it triggering 0 to the phasor~ and "reset" to my rate~ objects, this seams a hard pushed solution.

Hope you can help me with this issue and thanks a lot for all your inspiring work and tutorials.

Here is a small patch to test the problem.

sync_problem.maxpat

Hello Gregory.
I have a really important issue regarding sync between phasor and rate..
Every time I reset the phasor's phase to 0 and the rate's (@sync lock)  multiplier is different then 1, the rate's phase doesn't start from 0.. I was relying on this to trigger events and start from the beginning always the same way every time I wanted.

For the problem above I solved it triggering 0 to the phasor~ and "reset" to my rate~ objects, this seams a hard pushed solution.
Can you explain why is this happening ?

Hope you can help me with this issue and thanks a lot for all your inspiring work and tutorials.

Here is a small patch to test the problem.


My Favorite Object: rate~