There is a Noise UGen: Noisehttp://chuck.cs.princeton.edu/doc/program/ugen_full.html#noise Having said that,this shouldn't be any different from what you're explaining: Step randomValue => blackhole; fun void makeNoise() { while (true) { Math.rand2f(0.0,1.0) => randomValue.next; 1::samp => now; } } spork ~ makeNoise(); while (true) { <<< "random: ", randomValue.last() >>>; 1::second => now; } If you'd want smoother transitions between the random values, use an Envelope instead of Step and wait a it longer than samp between values. But I guess the Noise UGen is what you're after. :) /Stefan On Sun, Sep 26, 2010 at 12:44 PM, Thomas Girod wrote:

I didn't find any CNoise ugen - at least in ChucK online documentation. Are there any other extra ugens I can install ?

As for your other suggestion, this is not what I'm looking for. What you are describing is a random walk with a delay of X. What I need is a continuous change and a "freq" parameter that allows me to say how fast this continuous change is happening.

tom

On Sat, Sep 25, 2010 at 11:57:36AM -0400, Andrew C. Smith wrote:

...

There's a CNoise UGen, right? I believe that's what you're looking for. Otherwise, you can always spork a shred that gets a random value after every specified duration.

Let me know if that explanation didn't make sense and I can sketch up an example.

Andrew

On Sep 25, 2010, at 4:05 AM, Thomas Girod wrote:

...

Hi there.

I am looking for some kind of "random lfo" to change a parameter continuously and randomly. I remember there is a UGen called "LFNoise2" to do that in SuperCollider.

How can I do that with ChucK ?

thanks

tom _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Release me, insect, or I will destroy the Cosmos!

you are right, that is the kind of thing I'm looking for. The SubNoise + LPF technique is a nice workaround, too bad it doesn't work for very low frequencies. I've just had a quick look at SuperCollider's code for LFNoise, and it looks like they are generating new values at a rate defined by the noise frequency, and throw some non-linear interpolation inbetween. Tom On Sun, Sep 26, 2010 at 11:48:40AM -0700, Tom Lieber wrote:

It sounds like Thomas is looking for a noise generator with smoother output than Noise. I think Stefan was closest when he suggested sub-sampling Noise and interpolating the output. The easiest way to do this is SubNoise => LPF.

In this patch I save the output as a file so I can examine the shape in Audacity. I got terrible results for low values of freq like 1, but 5 and up look okay. I lowered the gain on the noise so that WvOut wouldn't clip.

5 => float freq; // rough frequency of the noise

SubNoise n => LPF lpf => WvOut wav => dac; ((second / samp) / freq) $ int => n.rate; .6 => n.gain; freq => lpf.freq; "subnoise.wav" => wav.wavFilename;

minute => now;

-- Tom Lieber http://AllTom.com/ http://favmusic.net/

I should mention that someone who's better at DSP than me probably knows why it doesn't work at low frequencies. Hopefully they chime in. :D

For very low frequencies one could also use a shred that sets a random target() to Envelope and feed Envelope a Step set to "1". Unlike subnoise this will be independent of the srate and the time can be set in musically meaningful terms like beats, assuming some are defined in the piece already. Hope that helps, Kas.

That'd also be a lot less smooth, right? You'd get a mountain range instead of a safety scissor edge.

Well, you'd get linear interpolation between random values. That might be great or crap, depending on your needs. I do think it has to count as "some sort of random LFO". You could filter the results, you could also wave-shape them but a wave-shaper that scales like that might be a bit counter-productive to implement.

And SubNoise is sample rate independent if you take the sample rate into account when you set its rate. :D

That does assume a infinite sample-rate. The result of a shred and a Envelope/step will also be quantised to the sample-clock, but the rounding error won't carry, like it will with setting SubNoise. Using a shred, a Step and a LPF will give you all of the advantages of a Subnoise and a LPF in the smoothness of the curve, without the timing errors, but it's also a lot more involved than a simple SubNoise.

This is the 1 Hz weirdness I noticed, by the way. The lines are noise generated at 5 Hz, 1.1 Hz, and 1 Hz. You can see the unnaturally long plateaus that get way out of hand at 1 Hz.

http://skitch.com/alltom/d25q8/subnoise

But the 5 Hz shape looks pretty nice.

That's strange! Those should indicate the LPF somehow ends up below the frequency of the subnoise and starts averaging too much. In any case it's not a bias in the randomness as the plateaus tend to run off towards 0. What I can say is that at higher frequencies the frequency resolution in steps per octave of SubNoise will go down and so you will get higher rounding errors in SubNoise. If that frequency ends up above the frequency of the LPF we might see something like what you are seeing? Yours, Kas.

Got it. I just learned something about SubNoise!

To larger or smaller amounts this is a factor in nearly all DSP. Flanks will normally be quantised to the sample-clock. This can affect timing a lot (as in the case of SubNoise) in small amounts of jitter (as in Enveloppe or SndBuf which will only start at clock pulses) or even in harmonics (as in the case of hard-sync). In some cases the effect is so minor it's not worth bothering with; I'm not that concerned about highhat samples being on average half a samp late, but in others it might be worth looking into. For example if osc A modulates osc B using hard-sync the actual reset will only be dealt with at the next clock pulse. If we are aware of osc A's phase and period we can calculate when the correct moment was, calculate what phase osc B should be at by now and set it to this, instead of a phase of 0. In this simple example that should only lead to a cleaner and -probably- more "pleasant" sound. In cases where feedback is involved not compensating for this behaviour will mean that a digital system in practice will behave wildly different from the idealised model we imagined. This is one of those surprising cases where a analogue system like the chips used in some FM chips meant for telephone modems will be far more stable and predictable than our digital systems, despite the common idea those are "perfect" or even "too perfect". Complex FM feedback on those chips can sound both extremely predictable and stable because while they may have far more noise this isn't as large a influence as the added complexity of quantising all modulations and resets to the sample-clock. Rounding errors occur in time, as well as in amplitude. Our "strongly timed" code may not be bothered by those that much, but a 44.1KHz sample clock certainly is. Yours, Kas.