@FFW @jameslo
a quick attempt,
with 9 slots, 2 seconds each
phasor~repeat.zip
UPDATED 3-times, sure this can be cleaned up debuged ... but I stop now
... and for each repeat this would need an additional phasor~ to start at the correct phase-state, I forgot this ...

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