Hi,

I am making a sample and hold that should modify the frequency control signal to a [phasor~].

This works:

My wondering is, would it be better to do this with [random]? Cpu is my main concern.

Thanks!

N.

@cfry Use [random]. [noise~] has to calculate 44100 random numbers per second, whether you do anything with those numbers or not. [random] just runs when you ask it to. Here are 10000 instances of [noise~] eating over half my CPU, and I'm ignoring their output:
and here are 10000 instances of [random] waiting for their next run:
Even when I ran all 10000, the event was too brief to register on the load meter.

Finally, you might not get the results you expect if your metronome speed is faster than the block processing rate. Notice the repetition every 3 bangs:

There's one case where you might use [noise~] and [samphold~] -- if the random step function is needed in the signal domain and you expect the sample/hold unit to update in the middle of an audio processing block. (There might be a way to use [random] in this case too, but I'm on my phone and won't work it out just now.)

When the random number is triggered by a control message, then [random] will absolutely be more efficient (by being idle while "holding").

hjh

Thank you for that neat explanation. It totally makes sense.

When I did a comparison test with just one of each (set to fast rate), the cpu load did not differ much but swayed around 7%. But that is actually just the basic load on my old computer.

@ddw_music said:

There's one case where you might use [noise~] and [samphold~] -- if the random step function is needed in the signal domain and you expect the sample/hold unit to update in the middle of an audio processing block. (There might be a way to use [random] in this case too, but I'm on my phone and won't work it out just now.)

When the random number is triggered by a control message, then [random] will absolutely be more efficient (by being idle while "holding").

hjh

Just for reference:

Proves that this what actually my situation (I guess).

I started to get this message:

(Tcl) INVALID COMMAND NAME: invalid command name ".x1072d5860.c"
    while executing
"$tkcanvas itemconfig $tag -text [::pdtk_text::unescape $text]"
    (procedure "pdtk_text_set" line 2)
    invoked from within
"pdtk_text_set .x1072d5860.c .x1072d5860.t10037fcc0 {-4.16 }"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 $docmds"

Once I removed my random sample and hold the message stopped occuring.

I am modifying an polyphonic FM synth, which has cloned objects with [phasor~] inside.

Could that error message be due to mismatched control/audio domain?

@cfry No, the quote posted by @ddw_music is related to PD's scheduler and the basic difference between update-rates of control versus signal~objects.
You can read about it in PD's manual chapter "scheduling" in the help-menu.

[noise~] has to calculate 44100 random numbers per second, whether you do anything with those numbers or not. [random] just runs when you ask it to.

... and you can poll it every 64 samples only.
That is why

There's one case where you might use [noise~] and [samphold~] -- if the random step function is needed in the signal domain and you expect the sample/hold unit to update in the middle of an audio processing block.

and why [noise~] with the output of [snapshot~] has no advantage over [random].

When I did a comparison test with just one of each (set to fast rate), the cpu load did not differ much

You will only feel the difference in huge patches with many [clone]s and or upsampling in the sum with many other things running.

I am modifying an polyphonic FM synth, which has cloned objects with [phasor~] inside.

Is the random generated inside of the [clone]?
If not, something else might cause high CPU-load.

The cheapest way to get random might not be calculating it in realtime, but reading preset random numbers from a text- or wavefile or an array with phasor~ or [f][+ 1]. But then the random set will loop.

Thanks. I am back on this now. The project went well, but I would like to get it right anyway.
@lacuna said:

... and you can poll it every 64 samples only.

and why [noise~] with the output of [snapshot~] has no advantage over [random].

I basically understand the difference between audio and control signals, but it is hard to apply it practice. The sample and hold simulation random function is modifying held notes, that is why I assumed it could be mismatches. In this case it may be that the control signal is not applied to the audio object until the next DSP update (after 64 samples) so it will not be a problem. Right?

Is the random generated inside of the [clone]?
If not, something else might cause high CPU-load.

The random is generated outside of the clones, but the audio objects inside the clones is affected by the random signal, continuously.

The cheapest way to get random might not be calculating it in realtime, but reading preset random numbers from a text- or wavefile or an array with phasor~ or [f][+ 1]. But then the random set will loop.

I do not think I need the to be super efficient cpu-wise in this case, I just do not want to make any mistales that overload the engine.

But what can that error message be a sign of, then?

I attach my patch.

The FM synth part comes from this tutorial:

pcoils.zip