take a look at [savestate] helpfile

Updated the patches:

Fixed 2 bugs:
Whole array size as default output.
Now also works if array-size changed.

And cleaned up messy counter.

Added array-sort example to helpfile, changed thread title.

@ddw_music This was also my second try, giving up the first. And my thoughts where similar, especially if LUA would be handy here? I did not care too much about speed as I don't need this for realtime. Anyway an object written in C would be faster.
(This array-sort is much faster than [list-abs/list-sort], did not try [text]sort.)
Still I don't understand your idea of building a list without rescanning the array or list for each peak? But don't worry if you are done with it ... If I only had known how much time I spend with this ....

@ddw_music Oh! Thank you! Yes, a minimal change in loading the 4th argument caused the bug! Moses! I might not have tested before uploading... blushing!!! Now I reuploaded it. Thank you
And this is quite slow... it is actually very slow. Wondering about a different approach.

Vanilla abstraction, made with [array-max] and [array-min] by nulling found peak and run again.

array-maxx.pd
array-maxx-help.pd
array-minn.pd

@porres read the first 3 or 5 posts of this thread and you will understand.
vsnapshot~ seems to return some arbitary? value.

(And we are trying to restore the 'internal double precision state of phasor~' from the outside in single precision. It turned out that this thread is not about block-boundaries, sample-accuracy ect. )

@jameslo said:

count the number of blocks from when dsp gets turned on, and then run a fresh phasor in fast forward that same amount of time to get back to that state.

This might be the closest we can get.
The patch may not exeed the total running time (all fast-forwards added up) of 32 bit space .

And ugly ....

(For DAW <> Pd I will open another thread some day when I am at it again. )

(forget ppphasor~ ...)

@porres vsnapshot~ is off
vsnapshot~isoff.pd

@FFW @jameslo @FFW @jameslo @FFW @jameslo
a quick attempt,
updated 100 times

now with one repeating sequence, 2 seconds , 50 phasors in parallel, I am done now, good night

ppphasor~repeat.zip

Thinking about [text sequence]... timing would not be double-accurate, so this might not work. Only rec/play the phaser as signal~ should work.

@FFW stop=frequency=0Hz State saving with cloned phasors~ running in parallel

And single precision is not enough for you?
Do you know what is not working in Pd64?
Did you think about other ways, like rec/playback?

Repeatability and linear recording/playback is the missing piece in Pd for me. I'd like to add a full blown time-line: Seamlessly connect Pd with a DAW.

You could record all patch-inputs/interaction (GUIs, ADC, HIDs) and skip to the time where you want to repeat.

I once tested this quickly with [text sequence] and sth. I don't remember now, (must have been some (IEM guts????) (send/receive canvas?????) external that sends/receives everything happening in a patch or canvas (might have been everything happening in the parent patch, as I have build a rec/playback external))... and that worked, but don't know about the precision of this. I think we can not get more than single precision in standard-pd. Here time would be single precision. But yes, everything is spooled (maybe not accurately): You can use [;pd fast-forward(. Recordings have not been editable ... so I'd prefer a DAW. But for what you are trying to do, it might be a work-around?

@jameslo Also maybe this helps? https://forum.pdpatchrepo.info/topic/10192/vphasor-and-vphasor2-subsample-accurate-phasors @Maelstorm

@jameslo I think all your assumptions are correct.

I'm just using it as an oscillator/LFO. Are you suggesting that there's a way to build an oscillator with [rpole~] that is as frequency-accurate as [phasor~] but without the single vs double precision issue?

No, as far as I understood:
Phasor~ is frequency-accurate, while compromising on the absolute y-value: Jitter in amplitude as little trade-off (which multiplied can become big).

On the contrary to a rpole~ramp, which is accurate in amplitude and accurately reproduces 'one-shots' sample-by-sample, but therefor must jitter in frequency when oscillating.

And I assumed wrong, maybe the correct amplitude would be most important for your application.
(The term phase of a ramp can be seen as amplitude or time.)
So I mentioned rpole~ solution.

the best it can do (without having to predict the future) is to return the last sample of the previous audio block.

Yes, you are right. Not a bug.
But it is not [phasor~] being slow (that is what I have been reading in your first post), it is [snapshot~] being one sample late.

Anyway, this thread is helpful for me, as I am slowly working on a state-saving-thing, and have not been aware of the 1-sample difference. Thank you.

Don't know about phasor's right inlet, but I guess for more precision on the outside of objects we'd have to use 'Pd double precision'.

Also remember @ddw_music different approach than [phasor~]: https://forum.pdpatchrepo.info/topic/14523/90-second-limit-on-audio-buffers

On one sample late: It is [snapshot~] who is early, not [phasor~]:

snapshot~islate.pd

So snap=$x2[0] would be actual right...
... in subpatch with [switch~] because [fexpr~] is so expensive ...
I would call this a bug of [snapshot~] !%§$*(

@elden said:

Please google "dynamic time warping".

Never tried this: https://github.com/irllabs/ml-lib
https://cycling74.com/forums/machine-learning-in-max-hallelujah

https://discourse.flucoma.org/search?q=dtw

The answers in this thread are all true... clone ... data structure design ....

@impression said:

So I think the core issue I’m running into is how to read out a list in a serial way

This is called list-drip. There are many [list-drip] objects in different libraries: Both, Vanilla abstractions and compiled ones.
And in list-help is "example3 list iterator". Changing [+ 1] to [+ 2] and [get $1 1( to [get $1 2( drips the list in pairs:

(btw where "store the remaining list" comment is wrong. It should be: read the list)

@kyro said:

I can't find the source to it anymore

In this thread
https://forum.pdpatchrepo.info/topic/8967/highpass-hip-not-working-as-expected/30
the last patch posted by @spacechild1 looks like this:

spacechild-hip.pd

Frequency and phase plot from help H14.all.pass

The question of how to tune an all-pass to compensate phase shifts of an IIR filter is also part of my interest.
How to calculate the phase response of an IIR and then build an all-pass with the inverse phase-response?
Maybe @manuels can help here?
Or is a machine learning approximation required?

On latency: As all-pass filters add latency (the phase-compensation is addition of frequency-dependent latency), I would not be surprised if the all-over latency would be in the same order with FIR filters for such a low cutoff-frequency.

Looking at the filter:

yes, try

[symbol $2$1(

instead of [$2$1( message.

I don't really understand your question. Maybe share a patch or screenshot to make it clear.
Don't know much about OSC, but I guess you are routing the incoming messages, don't you? So you could just route another name/adress?
Threre are many ways to archive things, in some cases dynamic patching is the only way, but this sounds like it maybe could be done easier.

A simple abstraction of a dynamic receive, a control rate [receive] with an input to change the receive name.
Made with dynamic patching.
Not sure sth like this already has been shared.

dynr.pd
dynr-help.pd

EDIT: there is an open request on Github: https://github.com/pure-data/pure-data/issues/603 So I guess [r.mmb] does this too.
LATE EDIT: and this one https://forum.pdpatchrepo.info/topic/13151/rd-a-receive-whose-argument-can-be-set-on-the-fly