@mt2002 what is the error message?

@navu this could be another simple Vanilla speedlim:

GUI slows down when being updated at high rates.
This already might happen with a single GUI. Visuals / eyes do not require such a high update rate as sound / ears does. (PAL framerate is 25 fps)

so Pd can freeze with

[x]
|
[metro 2]
|
[o]

while metro 60 runs smoothly.

Without knowing your patch, into the dark: Separate GUI updates (with [set $1( message to GUI object) from audio modulations [*~]. Where GUI updates at lower rate.

[set( message makes sure the GUI is only set (here for visuals) without output.

First thing I try when dealing with fast incoming messages are [change] and some sort of [speedlim] before the GUI:
There are many different ones from different libraries, with the same name [speedlim], and some may be Vanilla abstractions, but not sure about this, - and as far as I remember, someone posted a simple Vanila speedlim in the forum just recently?

https://deken.puredata.info/search.html?libraries=&objects=speedlim&descriptions=

(wish Pd had build-in some kind of global speedlim for GUIs ...or would get rid of TCL)

@polle yes

also see the help file of s~ r~

the former way has been, and still useful:

[block~ 1]
[array define fb 1]

[tabsend~ fb]

[tabreceive~ fb]

not sure if [block~ 1] [throw~ feedback] [catch~ feedback] can go down to 1 sample delay, but I think so

On naming:
[pd nameofsubpatch] is a subpatch
and your [bbt-waveguide] is an abstraction

Also be aware that the patch is calculated in blocks
and if you detatch the feedback-loop with s~ r~ or similar,
one-block-delay is introduced in the feedback.
64 samples, - as long as you do not put these abstractions in a reblocked subpatch: [block~ 1] in [pd subpatch]

offtopic but all those 1-sample delays in the abstraction (one of many ways to do this in Vanilla would be [rzero_rev~] ) are not required I guess.

there is the dsp-loop:

tcl/pd-gui.tcl

# set total_recentfiles 5
set total_recentfiles 10 

get number of channels in mc connections
https://github.com/pure-data/pure-data/issues/1989

missing/useful [snake~] methods
https://github.com/pure-data/pure-data/issues/1996

fastest and easiest, probably [env~].
or maybe this: https://forum.pdpatchrepo.info/topic/13046/a-movable-autoconnnecting-vu-meter-esp-for-debugging-code
or some oscilloscope abstraction

@fishcrystals @mkdewolf
control rate [line] output updates every 64th sample
signalrate [line~] does continuous ramp on each sample

Indeed, stairs require lowered anti-aliasing filtering at the output.

But does always any DAC need filtering, even for sines below Niquist??

Hmmm here the stairs are in the human hearing-range....

@JosephEoff @svanya take the multiband filter approach: https://forum.pdpatchrepo.info/topic/10268/what-s-your-favorite-noisegate/6

What would be a Vanilla replacement for [filter~]'s core ?

It doesn't have a help-file, I could only find the source with comments:

https://git.iem.at/pd/iemlib/-/blob/master/src/filter~.c?ref_type=heads

/* ---------- filter~ - slow dynamic filter-kernel 1. and 2. order ----------- */

It seems to have some interpolation algorithm to deal with the limited update rate of control-rate-only-inputs.
I don't need this, we can omit that, - just interested in what kind of filter is this?

it has several modes:

lp1, lp2, hp1, hp2,
lp1c, lp2c, hp1c, hp2c,
ap1, ap2, ap1c, ap2c,
bpq2, rbpq2, bsq2,
bpw2, rbpw2, bsw2,
dlp1, dlp2, dhp1, dhp2,
dlp1c, dlp2c, dhp1c, dhp2c,
dap1, dap2, dap1c, dap2c,
dbpq2, drbpq2, dbsq2,
dbpw2, drbpw2, dbsw2

And is used in many of IEMLIB's filters ...

Is this a biquad?

Still a mystery why the send-method works? Anyone knows?
And still wondering what drowning in symbols means?

In the extra spigot patch, you can get rid of [t a a] to maybe save some CPU cycles.
And maybe the send-method is cheaper than this.

[1 1, 0 0 5001(

rise till 1 in 1 ms, wait for 5000 ms then fall to 0 in 0 ms.

one more demux, currently I think it is perfect:

demux-morespigot.pd

And Zexy [mux] of course acts just the same, so no problem here. Nothing wrong with your example. @beep.beep

it should move the incoming [0( or [1( later in the execution order, rather than sooner.

Yes, as far as I know, it moves to the last position in the scheduler:
After everything else, but still in sync/at block-boundary. And I think we can rely on this.

But indeed, it is not a solution, as this doesn't work anymore:

demuxvsdemux-pipenotworking.pd

Yes, right-to-left order for outlets.
But connecting the loop to the right outlet, it happens again - yes, expected this time, but that is not consistent with Zexy's [demux]...

demuxvsdemux.pd

As mentioned above, the loop is unnecessary.
If behaviour of demux needs to be replicated some [del 0] or [pipe 0] might do.

same issue as an abstraction

oh! I didn't try, made wrong assumptions.

confusing!
Actually a subpatch doesn't make any difference about execution order. It is just the same as without subpatching. A patch with subpatches is still one patch.

As I read the patch with the output after click# 1, you must have been connecting the right hand [spigot] to the left inlet after you have created the loop between [t b b b] and [1( ?

Simply do this:

[o] 2) <--- this is your 2nd bang
|
[t b b b]

where the leftmost outlet goes to [1(
without any recursion-loop.

Or create an abstraction out of the subpatch, like [demux_vanilla]. Then connect everything around as you wish.
This way you make sure that the demuxer acts like a container: because then it really is a patch within a patch.

08.depthfirst shows that the whole chain of the right outlet of [trigger] is completed first. No matter what is in that chain (with the excepetion of what comes after [del] or [pipe], because these break the order).

G05.execution.order is about signalrate objects which have no intermediate connection, such as delay~lines, [s~] [r~], [throw~] [catch~], but not about control-objects' execution order.

On naming: The "v" in [vline~] or [vsnapshot~] indicates a more enhanced version (which can update in-beetween blocks) and has nothing to do with "Vanilla".