marlon brando

How do I filter whitenoise into pinknoise, brownnoise etc.

filtering-whitenoise-into-other-noise-colors

It's much more efficient to generate pink noise than to filter white noise.

If your real interest is a variety of noise sources, you should look at Litter Power. There is a useful variety in the free-but-more-Max-4-friendly Litter Starter Pack. Litter Pro has a greater selection and is Max-5 aware. There is far more than just pink and white. URLs below.

If you really, really, want to have filtered white noise, Tim Place's TAP tools do that.

If you really, really, really want to build your own filters, You'll need 6db/Octave, 12dB/Octave, etc db/Octave filters. As I said, building a 6dB/Oct filter is tricky.

It's much more efficient to generate pink noise than to filter white noise. 

If you really, really, want to have filtered white noise, Tim Place's TAP tools do that. 

If you really, really, really want to build your own filters, You'll need 6db/Octave, 12dB/Octave, etc db/Octave filters. As I said, building a 6dB/Oct filter is tricky.


white to pink would be best possible with fft i guess, but in practice you will use the [pink~] object for pink noise, and

rather use [pink~] to make "white noise" from it than the other way round, because of the [noise~] object outputting the same noise out of two instances.

"brown" isnt exactly a color, but it doesnt matter if we think it is, because somehow "brown" fits nicely between the sound of pink and white noise. 

to create brown noise and/or learn what brownian distribution is i would second the recommendation to look into the litter patches (or simply google it)

white to pink would be best possible with fft i guess, but in practice you will use the [pink~] object for pink noise, and
rather use [pink~] to make "white noise" from it than the other way round, because of the [noise~] object outputting the same noise out of two instances.
"brown" isnt exactly a color, but it doesnt matter if we think it is, because somehow "brown" fits nicely between the sound of pink and white noise. 
to create brown noise and/or learn what brownian distribution is i would second the recommendation to look into the litter patches (or simply google it)

Lowpass filter coefficents for pink noise from www.musicdsp.org:

num = [ 0.04957526213389 -0.06305581334498 0.01483220320740 ]

den = [ 1.00000000000000 -1.80116083982126 0.80257737639225 ]

2nd order, ~ +/- 0.9 dB error
num = [ 0.04957526213389 -0.06305581334498 0.01483220320740 ]
den = [ 1.00000000000000 -1.80116083982126 0.80257737639225 ]

and rather use [pink~] to make "white noise" from it than the other way round, because of the [noise~] object outputting the same noise out of two instances.

Quote:Quote:and rather use [pink~] to make "white noise" from it than the other way round, because of the [noise~] object outputting the same noise out of two instances.

wow, really! is that good news or bad news? ... gotta check my patches right now ...

Johan -- I'm afraid it really was a problem with Max 4. There are archived reports of people trying to generate triangular noise by subtracting the signal from to noise~ instances. Instead of triangular noise (which is what you should get) the two singals canceled each other out.

You had to instantiate the two objects during the same clock tick, which is why people thought their patches would work correctly while building them (who can create two noise~ objects within 16ms?). But save the file and reload -- wham! silence!

Litter Power's noise objects never had this problem. But there are still plenty of advantages to Litter Power that I don't begrudge Max 5 for finally getting this right!-

ComfortableInClouds wrote on Sat, 04 April 2009 16:25

Have you compared the CPU usage for this against lp.zzz~?

This isn't even a very good pink filter. TAP tools had a better one, but that really ate CPU.

Generating pink noise can be done a lot more efficiently.

ComfortableInClouds wrote on Sat, 04 April 2009 16:25Lowpass filter coefficents for pink noise from www.musicdsp.org:

This isn't even a very good pink filter. TAP tools had a better one, but that really ate CPU. 

Generating pink noise can be done a lot more efficiently.


you should be paying c74 for add space on here

Arg, I hate to do this because I don't like this kind of degenerative forum-list discourse, but Peter has been a terrific resource for the max/msp community for years. I've learned quite a bit from him myself, and his 'pimping' of Litter stuff reflects the *serious* investment in things-random that he has made (and a lot of what he discusses is actually free). Would it be better if he didn't mention what he knows is available? No.

Apologies for contributing to a thread that will surely deteriorate.

Arg, I hate to do this because I don't like this kind of degenerative forum-list discourse, but Peter has been a terrific resource for the max/msp community for years.  I've learned quite a bit from him myself, and his 'pimping' of Litter stuff reflects the *serious* investment in things-random that he has made (and a lot of what he discusses is actually free).  Would it be better if he didn't mention what he knows is available?  No.

why don't you just hit the ignore button?

Peter's "pimping" will never rub you again.

Do buy Litter though, it really is really, really good! 

why don't you just hit the ignore button?
Peter's "pimping" will never rub you again.

Do buy Litter though, it really is really, really good! 


Peter Castine wrote on Sun, 05 April 2009 16:14

btw, I just tried this, and indeed... after reloading the patch the signals from two instances of noise~ are identical.

only way to get around this, I guess, would be scripting the second (and nth..) instance of noise~, so it is seeded differently.

on Max5 this issue is fixed, but for people who are still clinging on to Max 4 while 5 goes through puberty (*raises hand*), this is good to know.

Peter Castine wrote on Sun, 05 April 2009 16:14Johan -- I'm afraid it really was a problem with Max 4. There are archived reports of people trying to generate triangular noise by subtracting the signal from to noise~ instances. Instead of triangular noise (which is what you should get) the two singals canceled each other out.

on Max5 this issue is fixed, but for people who are still clinging on to Max 4 while 5 goes through puberty (*raises hand*), this is good to know.


it is still true that pimp noise can simply be made by simply using [pimp~]. but nobody listens to me anyway.

Wow, I was really sure that noise had an optional argument to specify a seed for the randomness. I just checked the 4.6 and 5 references and clearly I am mistaken. Anyone know, was there some 3rd party object I am thinking of? Or was this just a complete MSP fantasy of mine.

I could be thinking of part of the free litter power if an object in there does it, but I don't think I ever really looked at those objects in detail.

Wow, I was really sure that noise had an optional argument to specify a seed for the randomness.  I just checked the 4.6 and 5 references and clearly I am mistaken.  Anyone know, was there some 3rd party object I am thinking of?  Or was this just a complete MSP fantasy of mine.

I could be thinking of part of the free litter power if an object in there does it, but I don't think I ever really looked at those objects in detail.


actually i always looked at it as a feature, because i a big patcher with dozens of noise objects, they simply do not need any CPU when they are all the same. this is why i am a bit scared off about "fixing the issue" in max 5 ... what if you need 2 objects to be the same? you have to rewrite the patch and use receive objects instead of noise~.

would have been a good idea maybe to make an additional object (white~ ?) but now it is too late.

[random] has seed, [expr rand (i)] and [noise~] did not have it.

but i believe they all used the same mac os random number function back in the days, which itself allows a seed value.

Roth wrote on Tue, 07 April 2009 03:48Wow, I was really sure that noise had an optional argument to specify a seed for the randomness.  I just checked the 4.6 and 5 references and clearly I am mistaken.  Anyone know, was there some 3rd party object I am thinking of?  Or was this just a complete MSP fantasy of mine.

actually i always looked at it as a feature, because i a big patcher with dozens of noise objects, they simply do not need any CPU when they are all the same. this is why i am a bit scared off about "fixing the issue" in max 5 ... what if you need 2 objects to be the same? you have to rewrite the patch and use receive objects instead of noise~.
would have been a good idea maybe to make an additional object (white~ ?) but now it is too late.

[random] has seed, [expr rand (i)] and [noise~] did not have it.
but i believe they all used the same mac os random number function back in the days, which itself allows a seed value.

Wow, I was really sure that noise had an optional argument to specify a seed for the randomness. I just checked the 4.6 and 5 references and clearly I am mistaken. Anyone know, was there some 3rd party object I am thinking of?

To be honest, I had thought about implementing a seed message for my noise objects, but on reflection it just seemed like a superfluous function. I *did* write code to guarantee that each noise object has a completely independent auto-seed, even if they are instantiated simultaneously. So each noise signal really is different. If you want the identical noise signal at different points in your patch, you can send~/receive~ (or s/r) from a single noise source. Or just use mutiple patch cords from the same source.

If someone can give me a really compelling reason for wanting correlated noise, I could implement it. It's not something anyone has ever asked for before.

Event-level random number generators are a different kettle of fish, and seed messages are available for every RNG object I know of.

Roth wrote on Tue, 07 April 2009 03:48Wow, I was really sure that noise had an optional argument to specify a seed for the randomness.  I just checked the 4.6 and 5 references and clearly I am mistaken.  Anyone know, was there some 3rd party object I am thinking of?

To be honest, I had thought about implementing a seed message for my noise objects, but on reflection it just seemed like a superfluous function. I *did* write code to guarantee that each noise object has a completely independent auto-seed, even if they are instantiated simultaneously. So each noise signal really is different. If you want the identical noise signal at different points in your patch, you can send~/receive~ (or s/r) from a single noise source. Or just use mutiple patch cords from the same source. 

Event-level random number generators are a different kettle of fish, and seed messages are available for every RNG object I know of.


Wow, that must bean I'm having dreams about fake MSP features. I totally remember being able to do that with [noise~]. I guess the people I told believed my dreams too.....

Roman Thilenius wrote on Tue, 07 April 2009 09:52

actually i always looked at it as a feature, because i a big patcher with dozens of noise objects, they simply do not need any CPU when they are all the same.

Actually, each [noise~] object is recalculating its pseudo-random number generator independently, so no CPU gain. It's just that each object is starting with the same parameter, so the output is identical.

Many years ago DDZ wrote to the list explaining that he used the algorithm from Numerical Recipes for [random] and [noise~]. Presumably analogously for all the other objects that need an RNG. Sorry if the following offends anyone, but I'm calling a spade a spade: the algorithm from Numerical Recipes is inferior to the one in the Classic Mac Quickdraw Utilities in terms of "randomness", and the QD random wasn't great, either. I don't know if this has changed, but I haven't noticed any release notes advertising enhancements to the core RNG used in Max.

I've already written that I don't see an awful lot of point to seeding an audio-rate RNG. Making sure that different instances have independent seeds is the important thing.

Roman Thilenius wrote on Tue, 07 April 2009 09:52actually i always looked at it as a feature, because i a big patcher with dozens of noise objects, they simply do not need any CPU when they are all the same.

Quote:[random] has seed, [expr rand (i)] and [noise~] did not have it.
but i believe they all used the same mac os random number function back in the days, which itself allows a seed value.

I've already written that I don't see an awful lot of point to seeding an audio-rate RNG. Making sure that different instances have independent seeds is the important thing.


filtering whitenoise into other noise colors