Hello,
I am trying to make a patch that defaults to making white noise, but can be altered to make pitched divisions based on the sample rate. Basically, I am using metro~ to bang a random object at the sample rate to make the brightest version of the noise, which should be banging at 44.1khz. But it does not seem to be banging this fast, because the initial noise sound is not very bright at all, and already sounds quite 'digitized'. I have attached the patch so far. Any ideas on how to make the initial sound basically identical to white noise?
digital_noise_1.pd

Could you try to describe your patch more? I am a little confused about how [counter] is interacting with everything, and that's due to my own pd shortcomings

In the mean time, you could try another possible route:

digital_noise.pd

Oops I think I did this patch backwards. I meant to cut everything below a desired frequency as well as cut everything above it, within a range of Q. I'll post a correction later.

Hi,
Basically, [counter] is effectively reducing the sample rate: metro~ sends out a bang 44,100 times per second, clocking the rate at which [random] produces a new number. [Counter] turns this rate to 1/2 the amount of bangs/second, 1/3 the amount, etc. so that the random signal (noise) will be half the frequency, a third, and so forth.
I will try your patch later, as I am not in a spot where I can test out your patch right now. However, by looking at it, it is not doing what I am trying to do (generate a noise signal that can be modified from it original generation), as it already begins with a [noise~] object.
Thanks!

@nikvudu Ok I understand what you are trying to do. Although I am confused because if you are effectively reducing your samplerate, you are essentially limiting the amount of high frequency content you can represent, so the sound "not being bright at all" is an unavoidable consequence. Someone more knowledgable than I should chime in

@rjp9 Also, I'm not sure what [metro 200] is doing, because I can't hear a difference if it is turned on or off. [bang~] outputs a bang every block cycle (default is 64 samples I believe), and there are 44.1 samples in a ms (assuming 44.1khz samplerate), so you are not generating a bang at a 44.1khz rate, but something like 30.4khz ((44.1/64)*44100). To remedy this you could try setting your default blocksize to 1.

why don't you just use noise~? it does the exact thing that [random] does, but at signal rate. I think this is what you want

[noise~]   [phasor~ 500]
 \         /
 [samphold~]

where 500 is the frequency of the noise

I was reading Dodge & Jerse's book Computer music and it mentions that noise generated in this manner will have fewer high frequency components.
But they also give a method to generate pitched noise:
linearly interpolate the noise that is sampled at less than the sample rate, then ring modulate it with a sine wave at the desired frequency. However you need the current sample and the last one for linear interpolation, which pd can't do easily though you could perhaps rig something with delays) My library has stuff that could do that also. (linterp~ with shnoise~)

The [metro 200] is actually not supposed to be there, it was for a different method I was trying out for a bit but did not fully delete.
Ahhh ok! I guess I am still confused about what exactly a block cycle is and what it is for. I think I was assuming that metro~ outputs a bang for each sample, not for each block cycle.
I know that reducing the sample rate will make it less bright as it reduces high frequency content, but I was trying to make the default setting of this patch basically indiscernible from white noise, so that it only gets less bright when you hit the message boxes other than 1.
Thanks for your help, I will try changing block size.

Unfortunately you will never be able to pass messages to signal-rate objects faster than 64 samples and have it affect the object's signal no matter the block size
the reason for this is that all messages within 64 samples are resolved simultaneously, it is only through signal objects and message-rate object interaction that timing differences below 64 samples from objects like [metro] and [delay] become "real"
Just a hint: whenever you find yourself generating every sample for use in synthesis by using message-rate, you should try to do whatever it is in the signal domain if at all possible.

@nikvudu

I think I was assuming that metro~ outputs a bang for each sample, not for each block cycle.

You mean [bang~] right? I don't have a [metro~] object in 43.4

I guess I am still confused about what exactly a block cycle is and what it is for.

From: http://booki.flossmanuals.net/pure-data/_full/ "Computers tend to process information in batches or chunks. In Pd, these are known as Blocks. One block represents the number of audio samples which Pd will compute before giving output. The default block size in Pd is 64, which means that every 64 samples, Pd makes every calculation needed on the sound and when all these calculations are finished, then the patch will output sound."