Hi there,

this again deals with some kind of hard syncing ... I know this is tricky.

Let's say I play a sample constantly varying the playing speed (fwd/back enabled). This speed is read in an array, every 3 ms. This "automation" warps the playing time of my sample.
Now let's say I want to know the "playing" time of my sample when played "warped" by this automation, with a "simple" criterion : I reached the last sample.

It's a time integration with no means of deciding when you stop it ...

Any idea ?

Nau

when i have done something similar to that, i did it this way:

instead of using a [phasor~] to drive the sample playback, i used my own handbuilt phaser~ constructed with a [metro], a [f ]x[+ 1] counter, and a [vline~] object.

see the attached patch.

this is done for speed change every 1ms, but you can adjust it for your 3ms by simple multiplication of values.

http://www.pdpatchrepo.info/hurleur/easy-timer.pd

Thanks Mod,

glad to see that I did exactly the same polygonal [vline~] scheme as a first version of my patch. But this is not very accurate ([moses] doesn't work at audio rate), if not missing something...

In fact I abandoned this strategy for [phasor~]'s since it's the only way I found to loop correctly (sample-wise) when automation is disabled (constant unitary playing speed, i.e. "normal playing").

Thank you anyway !

Nau

attached is the test patch i just did for timing accuracy.

total recorded file length is always within about 2 milliseconds of what the patch tells me it should be.

given that i have 1ms between metro bangs, that accounts for 1ms

not too sure what other sources of that error may be. my guess is that writesf~ only gets triggered on block boundaries? or else i am doing something wrong with [timer]?

however, it does seem pretty accurate.

do you positively need it to be accurate to within 1 sample or something??

http://www.pdpatchrepo.info/hurleur/easy-timer-write.pd

You can use [rpole~ 1] as a sample-by-sample accumulator. So you could get the total time in ms like this:

[pd is.it.playing]
| /
[rpole~ 1] /
| /
[/~ 44.1] /
| /
[samphold~]

The tricky part will be what's inside [pd is.it.playing]. While your sample is playing, it should send a 1 signal to [rpole~], and while it's not it should send a 0 signal. That same switch can be used to trigger a [samphold~] at the end to grab the total time. Also, you'll need to clear the filter once you've reached the end to start it over. If you don't do all that, it will shoot off to infinity and explode.

Yop,

Thanx again Mod. The accuracy proposed by "message rate" computing can be judged "good" in many situations. I got this far last week, but just wanted to know if there was an elegant workaround for this "audio rate brickwall" I bang my head against here and there in my daily Pd journey.

Thanx Maelstorm. I'll follow your suggestion, I'm very curious as this seems to be a rather elegant way of working. Now I'll be able to integrate time, provided I find a trick to send 1 while playing and 0 when not to the [rpole~ 1]. I think I'll use [vline~] strategy to allow the index values sent to an "mask" array to go above sample size. This way if my "mask" array has ones everywhere but zeros above the sample length it could work.
This would be a "fusion" between Mod's and Maelstorm's suggestions.

Again, this confirms my opinion that "just asking" on this forum leads nearly always to new possibilities...

Nau

wow maelstorm, that is neat.

Works flawlessly !
Simply created another array that has the same lengh as the original sample and a constant value of 1 using a 'const' msg. This array is played in parallel with the sample with my "drunk playing head", and when the [vline~] tries to read an index above the original sample's size the result is zero, thus letting the [rpole~ 1] accumulating zeroes. The output of [rpole~ 1] is then (soon, but not at audio rate) read by a [snapshot~] and can be displayed.

Thanx again.

Nau

Nice. You might be able save memory on the other array by just testing that the index is below the max index:

[vline~] [r number.of.samples]
| /\
| / \
[*~ 1] \
| \
[expr~ $v1<$f2]

Or some variation of that that fits with your implementation.