@jameslo The bug is the delaylines~ not having 1 sample delay.
I am not entirely sure why, but you read them at 0ms, - arguments are in ms not samples and there is the importance of the execution order with delays~, and s~ r~, you can read about in audio.examples/G05.execution.order.pd
But this would lead to a DSP-loop here.
However, I use tabsend~ tabreceive~ and 1 sample arrays, as this is how to do feedback-loops with 1 sample delay.
I created the sending subpatches first, the receiving ones afterwards, - not sure if this is important for the execution order in this case, too?
help > find externals
And please read how to deal with externals in the manual: help > manual > chapter 4 externals
To be sure, delete the zexy folder in /extra before reinstalling it with Deken
(Also, I'd recommend to download the latest version of PD Vanilla from here https://puredata.info/downloads
or there http://msp.ucsd.edu/software.html
instead of using possibly outdated repositories (i.e. Synaptics). But this is unrelated to your question. )
@pharaoh-sean After installing Zexy via Deken,
try adding zexy to File > Preferences > Libraries
[declare -lib zexy]
in your patch.
In File > Preferences > Searchpaths should be PD's /extra folder, and the library should be inside of that folder, of course.
similiar thread here:
@adammccaffrey you can find the error message in the sources:
the patch is resizing the cloned arrays
here it uses >4Gb of ram
operating system? 32 / 64 bit?
PD-version? 32 /64 bit?
@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.