@oid said:

this won't work if you have more than one instance of the middle abstraction

I knew I was missing sth.

Can we do

[savestate]
/
[route menusave]
|
[menusave(
|
[sendcanvas]

using the right outlet bang of [savestate] in the middlepatch, then [savestate] in the child as intended.

I agree with @alexandros init state should work, but in an abstraction it doesn't.

if this is the case maybe you could do a work around by sending dirty message to the middle patch, similar to how I did there:
https://forum.pdpatchrepo.info/topic/15732/how-to-save-restore-multiple-0-array-abstractions-in-a-patch/4 maybe with metro instead of ping, this way you get asked to save before closing.

[namecanvas $0-parent]

[loadbang]
|
[1(
|
[metro 20000|
|
[dirty 1 (
|
[s $0- parent]

@witteruis ctrl+click on the red error line to find the error.
Read here below Fig. 2.1.7 https://msp.ucsd.edu/Pd_documentation/resources/chapter2.htm

[osc~] [osc~]
|      |
[max~   ]

or with [min~], this switches the signals themselfs

Decision of using control-rate or signal-rate basicly depends on where the trigger is coming from: signal-rate or control-rate?
(this is the short answer)

I'm not clear on what value "le+23" is meant to indicate.

1e+23 is just a very big number (+ - 1e+32 is Pd's 32-bit single precision space). By multiplying the output of [rzero~ 1] to extremes, then clipping with [clip~ -2 0], turns it into a boolean, either -2 or 0.

Here is @jameslo's example of sigrate flipflop https://forum.pdpatchrepo.info/topic/13918/signal-logic-clocks-division-and-sequences/4
rpole~version should be drop-in replacement.

I tried those

please share your patch

https://forum.pdpatchrepo.info/topic/15750/audio-rate-flipflop

Now looking at this years later, in hope that I don't miss the point again:

@ddw_music said:

This naïve approach to timestamps will work only if there is ever only one pending message. If the sender spits out 5 OSC messages with different future timestamps, only the last message will be available in [list store].

The reason for this is that there are only one [delay] and [list store] for several messages.
Haven't tested but I think this works: clone [del] and [list store], and feed the clone with

|
[list prepend next]
|
[list trim]
|

EDIT: looking further, haven't tried this neither, but in osc lib, which contains [unpackOSC], is also [pipelist].

connect the $1 to inlet~ instead of pow~

inlet~ helpfile

Connect [f $1] to [inlet~].
Or use [sig~ $1] ? Not sure what you want to do?

Try to undestand the patch and read the manual, esp. 2 control.examples / 08.depthfirst.pd

Vanilla's Changelog (don't know if this is complete):
https://msp.ucsd.edu/Pd_documentation/resources/chapter5.htm

You probably used Pd-Extended 15 years ago!?
Extended is discontinued, but you can add libraries to Vanilla.
There is 'Deken' now: Pd-menu > help > find externals online .
There is also this website of Deken, which helps to find missing objects: deken.puredata.info
So [init] is part of IEMlib.
But is also easily replaceble as Vanilla abstraction:

[loadbang]
|
[args 0(
|
[pdcontrol]
|
[list trim] [inlet]
|/
[outlet]

pdcontrol did not exist 15 years ago.
All Vanilla objects: help > list of all objects

And there is the compatibility message to revert Vanilla to an old version:
[;pd compatibility 0.52(

see message-helpfile > pd-messages

There have been many many improvements to Pd, intelligent patching for example.
And documentation also improved a lot!

It has been a big shift when Pd went from 32 to 64 bit. In this transition some libraries have not been updated and I think it has been that time where Extended discontinued. You can still download it and run your old patches there ...

EDIT: more on finding externals or abstractions:
https://forum.pdpatchrepo.info/topic/15770/harmonic-amplification/4

@jamcultur I can reproduce this. Feels like a bug but I think it is the nature of abstractions saving confilicting with the array saving.
As workaround we can do our own array saving with [savestate]

arrayabs.pd
arrayabsopenthis.pd

@Balwyn said:

anything else opens the spigot

would be this:

in your patch only floats open the spigot

Maybe the answer is in this video of Millers classes at 1:04:00
https://msp.ucsd.edu/syllabi/206.20s/movies/5b.may1.mp4
sorting starts at 59:19:15
overview: https://msp.ucsd.edu/syllabi/206.20s/index.htm

A comma in a message means "now comes another message"
so [1, 2(
is the same as
[t b b]
| |
[2( [1(

So you could separate your two messages to subpatch with a comma instead of writing ;subpatch again. (where the semicolon means "send to")

@jameslo And when filtering zero, there are different timings at different samplerates and dsp on/off also differs.
At 48kHz samplerate and dsp off, lowest is 4 ms but very very rarely goes as low as 2.66667 ms.

slider-min-update-rate-nonzero.pd

@jameslo wtf I expected 64 samples. It can go down to zero:
slider-min-update-rate.pd

Is this related related? [Pd-list] pd-gui update rate (2011)
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/thread/NFL5EIGEJQII7G5X5FXGM2WXDM6W4263/#KJSQGTRBJVBZGMQPHFYRGYBQXN7GSOZL

Press control+shift+escape to open the task manager, in details you can right click on wish86.exe and or pd.exe and define the allowed cores for the application.
I never tryed this but just saw it there now.
As @whale-av said, maybe you have to copy the pd folder and maybe rename the second application.
I guess there are other ways to start and run applications on a specific thread in win, but you can search for yourself as this is not Pd specific.

And as @whale-av said, these instances are completly independent and they
won't run in sync. They run asynchronous. Useful for special tasks, for example to do sth with fast-forward-message while the other patch stays in real-time.

If you want to spread patches across different cpu cores but still in sync, use the [pd~] object.

Either way shmem lib is very useful to share memory / share arrays between pd-instances.

(Looking at the task-manager when using [pd~] I see the cores are constanly changing, Looks like Windows is dynamicly changing the cores. Might be good enough or even better to let Windows manage it instead of assigning fixed threads. Same might be true when running asynchronous instances. )

send a [clear( message to all filters

take a look at [savestate] helpfile