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