I'm working through the complex number pages at http://www.katjaas.nl/home/home.html using PD as my lab. Is this the right place to discuss? If not, please let me know where I should be posting my questions.

I'm currently struggling with her description of the resonator at the heart of a biquad filter .

Up to this point I've been able to build working examples based on the signal flow diagrams and duplicate her results, but for some reason this one is not behaving. From her discussion I expected to see huge eliptical orbits, but the best I can achieve is a pulse train at half Nyquist when omega=pi/2 and r=1. Otherwise I just get tiny single pulses. What am I misunderstanding?

Here's my patch: biquad resonator.pd. You can totally ignore Gem unless you want to see the Lissajous curve (which is dull given it's current broken state).

@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

@lacuna Thank you, you're absolutely right, 3 day mystery solved. I just recently switched from using [block~ 1], [tabsend~] and [tabreceive~] for 1 sample delays to using delay lines, but that short cut of asking for a 0 ms delay (and getting a 1 block delay instead) is dependent on a specific tilde object sort order. I don't think [tabsend~] and [tabreceive~] has that dependency or the creation order dependency, so I think I'll switch back.

@jameslo ohoh, you stumbled across something here...

first, @lacuna is not exactly right, the delay lines give you one sample delay as expected since the blocksize in the subpatch is 1.

so what is wrong with the patch?
here is an example:
working.pd
not_working.pd
spot the difference....... right, there is none!
The only difference between these two patches is that i created the "delwrite~/delread~ phase2Delay" after "phase1Delay" in the working example. (And i assume you created the "phase1Delay" after "phase2Delay" in the patch you shared)
Pd sorts the dsp processing of the delay lines in the order of creation. You can do the execution order thing to get it right:
execorder.pd
..but you should complain about this in the pd-mailing list because this strange behavior of pd is not properly documented anywhere it seems.

by the way, the working patch generates some very nice psychedelic mandalas when you feed it with an impulse generator : )

@solipp It is sort of documented in G05..... where subpatches are recommended to force order of execution.
David.

@whale-av well, sort of... it is nowhere documented that you can mess up a working patch with two concatenated delay lines simply because you give one of the delwrites~ a new argument.

@solipp Hilarious!
unexpected tilde object sort order.pd

Improved reading comprehension update: I can't reproduce by editing the delwrite~s, only the delread~ I marked. Still funny though.