@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.

Maybe [receive $1] inside the abstraction. Or [value $1]. Or both (to get the value when abstraction is loaded and new value is sent).

[123\ 
|
[s $0-a]


[abstraction $0 a]

[r $1-$2]
|
[print]

[loadbang]
|
[v $1-$2]
|
[print]

https://www.flucoma.org/

Yes, indeed, just for display.
And polygon surprisingly is the cheapest option of the three.

For interpolation [cyclone/wave~] has more options, such as cubic, spline, Hermite and Lagrange as [tabread4~].

The [open $1, 1( are two successive messages: [open $1( and [1(, where the later is the same as [start(

Many (but not all) objects can update only at block boundaries of Pd's main blocks (fixed blocksize of 64 samples in standard Pd) .

One block of 64 samples at 44,1 kHz samplerate = 64*1second/44.1 kHz=1.451 ms

Use [vline~] instead.

[tabread] instead of [array get] !?
(Long time ago arrays where called tables in Pd.)
Read their helpfiles. You can use [array get] too, but more complicated for this.

In Pd Vanilla, right click on the blank canvas > help shows all build-in objects.

@seb-harmonik.ar 2048 points since Pd version 0.55 :
https://msp.ucsd.edu/Pd_documentation/resources/chapter5.htm#s5.1

There is a mapping equation:
https://forum.pdpatchrepo.info/topic/14355/limiting-amplitude-on-an-lfo/12

And with [mtof] (midi to frequency) you can get that exponential/logarithmic pitch to frequency curve.

@jameslo For me it is difficult to understand. Maybe I am missing the whole point and all I say is off topic.

First of all, I honestly don't understand why your left bang works

click bang [o] (GUI always on block-boundary) > [spigot] opens > [bang~] bangs > [spigot] closes > [vline~] starts (still on same block-boundary).

Similarly, in my first response to you, you can see in the snapshots that the bang from [delay 1.5 64 samp] is being processed during Ctrl 1, 32 samples before its real timing.

This I don't understand.
You use [rpole~ 1] as sample-counter, right? But [snapshot~] only snapshots on block-boundaries. (That's why there is [vsnapshot~], but that was buggy, when I last tried it.) [snapshot~] shows 64 samples, one whole block.
If you snapshot later, you see [del 1.5 64] outputs bang after 96 samples:

([sig~] also updates its output only on block-boundaries, not within the block.)

@seb-harmonik-ar s [pip~] could be done with [bang~] and [timer], to measure the time that has passed into the block.
Or for signalrate~ output~ with [rpole~ 1], to measure the samples past into the block.

you don't need to predict the future to make it one block earlier

So is it correct that you want to move the start of vline~ 'backward' ? To the start of the block? To the start of that block where [del] outputs later on a message to [vline~]?
Clicking [o] bang at ctrl 0 > [del 1] outputs after 1 ms, where audio 0 is happening > [vline~] should have started before, at the beginning of audio 0 ?
Is this what you want?

Here is a paper where message- vs signal-domain and scheduleing are graphed. It is in German, maybe you can use a translator and the time-graphs on the last pages are english / self-explanatory. And you problably already know all of this.
https://iaem.at/kurse/ss19/iaa/pdscheduler.pdf/view

@jameslo Thought that's what you where looking for? 'block-quatizer'?
But you want to move the output of [del 1] back to the start of the block?
Interesting, but I think moving backward is not possible in realtime Pd ... (hmmm there is the [lrshift~] object for moving in a block... )

Edit: My point was that this quantizes to (next) block boundary, and if already at it, it stays there.
[del 0] Breaks the deterministic order ( [t b b] ect.), as [delay] and [pipe] always do, and moves to the last point after everything else deterministic is processed, but keeps at the same logical time (zero delay).
But what was your point?
Edit: Now I tried without [del 0] and everything is the same. So I completely missed your point??

@jameslo said:

In the middle of a message cascade you may schedule another one at a delay of zero. This delayed cascade happens after the present cascade has finished, but at the same logical time".

Man, this got me excited because the only reason my bang quantizer outputs where it does and not one block earlier is because [bang~] for the end of the first block has already executed by the time my spigot opens and so we have to wait for the next audio block to complete. I was hoping [delay 0] would cause the bang from [bang~] to be rescheduled after my spigot opens, but it doesn't appear to.

That works, screenshot when left bang is clicked:

vline~blockquantizer.pd

(thought [bang~] would be expensive, that's why I [switch~]ed it in the other patch.)

@jameslo said:

Is there a way to zero out that bang timing attribute, so that the bangs are quantized to block boundaries? Or some other way to force [vline~] to start at the beginning of the next audio block?

Like this?
vline~onnextblockboundary.pd

Edit: it's not just bangs that have that intra-block timing attribute--you can see in my example that it's preserved through the message that's sent to [vline~]

As far as I understand it now, some objects
([metro] [del] [pipe] [vline~] maybe[vsnapshot~])
do intra-block-messaging/banging and some won't (like [tabwrite~] in my patch).

The scheduler processes GUI and Midi i/o at block-boundaries.

I am highly interested in how to sync or interface Reaper or other DAW with PD control rate sample-accurately intra-blocks.