@andrearkham Might need some externals (it is old), and might not be what you need......
https://forum.pdpatchrepo.info/topic/3274/speech-formant-synthesizer-with-bonus-turkish-vowels-pack-p
David.

@willblackhurst If you look at the help file for [tabread4~] you will see that correct interpolation requires guard points added to the array so that interpolation is performed correctly as [phasor~] wraps around the end of the array.
Your patch doesn't glitch between the array copies, but it does as [phasor~] wraps at the end of the 3rd copy, or where you chop into the array adjusting the clip length percentage.
@lacuna made a handy patch to add guard points automatically.... https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-of-an-array-for-4-point-interpolation-of-tabread4-ect
I suppose that if you want to adjust the playback length then you would need to copy a percentage of the array to a new array, and then add the guard points.
David.

@jameslo Yes, it seems to work with the $0 inside or at the end of the name....
David.

@jameslo Can you make it work something like this?
I would expect that $0 can be used in the name as they are both objects.... but I am so confident that I didn't check.....
David.

It seems to update [value me]....... maybe.pd

@Coalman Nearly...... see [sort-help] from the zexy library, which contains what could be a specified list randomiser if a $ argument is added to [pd randompackage].....
No post sort routing though.
David.

@Coalman Probably the list-abs library....... maybe [list-wrandom]..?
Although the list-abs library comprises vanilla abstractions.
David.

@avenir I agree with @alexandros , as it seems what you are trying to achieve is convolution but only for volume, in which case you could send [tabread4~] into [env~] and give [env~] a big enough window size to smooth the envelope which you will multiply by the output of [noise~].
David.

@jameslo Schrodinger would have a word with you...
I think knowing the applied output of [phasor~] is enough, as it is the only "known" and is determinable. Capturing at audio rate timing also gives almost unfathomable precision given the bit depth at 64-bit. Go for 192kHz sample rate if you want. Although such timing is not really human relatable it could make a difference when multiplied in the signal domain.
I know, I am setting myself up for some pushback....

More ramblings.....
It should be a new thread I suppose, but it would be good to establish exactly the data points reported by [snapshot~] and [print~] etc.
I think it has been discussed before so I will try to dig it out.
@lacuna [snapshot~] is continuously taking snapshots of the last value of a block. That is demonstrated by the fact that when banged with dsp off it reports a value. Not sure that it can be called a bug, but it needs to be widely known.
When [print~] is banged with dsp off nothing is printed, and it will print the block following the bang with dsp on. Its first reported value is the next sample after the [snapshot~] value if they are banged at the same time.

Yes, @porres for sample accurate timing we do have all the "v" objects but if the patch is controlled at block boundaries then repetition of actions is still accurate, simply the original command and the repeated command both occur at exactly the block boundary.
Assuming that [phasor~] always starts at 0 when the patch is created the commands are repeatable.

Using "v" objects is slightly more complicated as it is documented for example that [vline~] starts its ramp one sample early.
Vanilla [vsnapshot~] is still documented.... "- mal-designed snapshot~ extension, best not to use this".

So a time graph of samples over 2 blocks, with "v" and "non-v" objects overlaid showing their data points and trigger points would be a very useful reference document I think.
I know I am making work for you, but somewhere I got the idea that you enjoy it... !
David.

@jameslo A very different approach (which seems to work) by suspending dsp processing in the sub-patch and re-starting when you wish to repeat the [phasor~] sequence (it should be accurate but could need better testing by external graphing..!!)....... phasor-store.pd
In 32-bit Pd it seems to be accurate for value only to 1/1000 but in 64-bit 1/10000 or greater.

This method does not restore the master [phasor~] so a switch to using the slave would be necessary as the sequence is restored.... and it is single use.

I cannot fathom for now how the same accuracy could be saved and recalled for a future start of a patch, apart from saving an [array] of a [phasor~] output.
David.

@avenir Thank you for testing.
Should get there in the end..... cart-5-vanilla.zip
David.

@avenir Ah...! .. I missed one old 32-bit external.
A track display error fixed too.
Should be good now I hope........ cart-5-vanilla.zip
David.

@avenir This will give you a list of files in a folder and let you play them with [readsf~].
You can replace the player part with [soundfiler] and arrays as above.
cart-5-vanilla.zip
David.

@atux You should get the list-abs library. It is a library of abstractions.... so vanilla.... and a real swiss army knife for dealing with lists and other manipulations.
The abstraction you want for that is [list-sieve]..... list-sieve.zip
The library is a must... it saves constantly re-inventing the wheel.
David.

@atux

@porres From one 5 year old to another....
A Neural Net attempts to replicate a brain..... treats snippets of language and information as if they were stored in neurons.
Starting with some instructions (rules) from a programmer it then looks for likely links between those "neurons" and builds new rules based on data matches and the probability that it will return the correct output. We don't know how the brain works, so the maths involved is somebody's best guess.
Given the high percentage of garbage LLM's scour on the net they have a quite high failure rate, which gets worse as the model grows and feeds also on garbage outputs. For a while now its language construction is excellent, causing humans to believe that far more of its output is correct than is actually the case.
Unfortunately newer models are also proving to be worse than their predecessors.

A neural net trained on a smaller data set in Pd might be better, and the initial rules easier to fathom...?
David.
.

@polyplexmescalia Can be done, and probably by other means too.
Try this...... this.zip
David.

@ben.wes Have you seen @katjav's site...?
https://www.katjaas.nl/home/home.html
There is some of her thinking on this subject in / applied tech / low latency FIR filters.
David.

@Vnms It is not easy, and I gave up myself.
If you don't mind using externals then the ggee library has objects that calculate the parameters...... for[lowpass] [equalizer] and [highpass].
David.

@FFW Yes...... well it was in Pd extended..... so maybe......
You would need to modify [mouse_region] from the HCS library.
It shows coordinates and constrains output to the mouse presence inside the GOP area.
You would need to remove the mouse click and drag constraint, using just the position so that you get bangs or coordinates only when the mouse is in the gop area.
It needs externals from PurePd and others probably.
You will be able to modify it to do what you want, and it should be more simple when done.
There will be other ways to achieve the same thing as long as you have the mouse coordinates from the window...... coordinates from the screen would not work.
David.

@Josefo18 There was a discussion long ago..... https://forum.pdpatchrepo.info/topic/6003/rap-realtime-analysis-project where [sigmund~] and [bonk~] were mentioned.
@katjav investigated SNAC on her site...... https://www.katjaas.nl/helmholtz/helmholtz.html
... and at the bottom of that page she posted [helmholz~] which might be what you are looking for.
David.