@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?
biquad-resonator-debug_2c.pd

@pharaoh-sean
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. )

@RetroMaximus mapping might help
map.pd
map-help.pd

@pharaoh-sean After installing Zexy via Deken,

try adding zexy to File > Preferences > Libraries

or add
[declare -lib zexy]
beforehand
[demux]
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:
https://forum.pdpatchrepo.info/topic/12786/iemlib-in-vanilla-deken-compiling/11

@adammccaffrey you can find the error message in the sources:
https://github.com/pure-data/pure-data/blob/master/src/m_memory.c

the patch is resizing the cloned arrays
here it uses >4Gb of ram

operating system? 32 / 64 bit?
PD-version? 32 /64 bit?

@adammccaffrey probably running out of memory.
How much Random Access Memory does your machine have?

@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.

@whale-av @jameslo
now [declare -lib iemlib] made it with 1.22 from Deken on Win10
sorry for the false alarm! and thank you *

@whale-av does t3_delay-help.pd work on your machine?

now checked 1.16 from iem site and there is a /lib folder inside the /iemlib folder with iem_t3_lib.dll
But still doesnt work. And no t3 object .pd files ...