[PD] checking [readsf~]'s current position in wav-file

[Jakob]

Hello all!
Thanks for all your replies! With your help I was now able to implement a solution by calculating and checking the play time of the sample.
Cheers!

> Am 20.11.2019 um 17:32 schrieb Miller Puckette <msp at ucsd.edu>:
> 
> Just a reminder - send the "open" message at least a tenth of a second in
> advance of the "start" message to avoid glitches in the output.  If you
> want to loop a soundfile, use two readsf~ objects in turn (and then, for
> bonus points, you can cross-fade them to avoid clicks at the loop point).
> 
> If sub-millisecond timing is desired, note that the output always starts on a
> 64-sample boundary; you can use bang~ and timer to measure the time since the
> last block started and give the "start" message an advance in samples to
> avoid audible jitters.
> 
> cheers
> Miller
> 
>> On Wed, Nov 20, 2019 at 08:52:52AM +0100, Roman Haefeli wrote:
>>> On Tue, 2019-11-19 at 21:39 +0100, Jakob Laue wrote:
>>> Hey all,
>>> I want to play a wav-file with [readsf~] and I want to loop the wav-
>>> file.
>>> This can easily be done by connecting [readsf~]'s right outlet it its
>>> inlet.
>>> The problem is that I have a metronome in my patch which is the
>>> master of the tempo.
>>> The [readsf~] object will get out of sync with the metronome when it
>>> loops the same file over a longer period of time.
>>> That's why I want to constantly check the position of the wav-
>>> file that [readsf~] is currently at, when it plays the wav-file.
>>> By this, I can restart/loop the wav-file in sync with the metronome,
>>> as soon as it has almost reached its end.
>>> Do you have an idea how I could do that?
>> 
>> You should definitely start each loop in sync with the metronome. It
>> seems you're letting [readsf~ ] playback loop itself by using the end
>> bang to trigger playback again. This is not wrong, but if the length of
>> your soundfile doesn't match exactly a multiple of your metro period,
>> then metro and loop playback will drift apart.
>> 
>> Pd is absolutely deterministic. There is no need to ask [readsf~] for
>> the current cursor position. You can derive it from the time that has
>> passed since you started it. But even that would only be necessary if
>> you have user input and you want to determine current playback position
>> at time of user input. 
>> 
>> If my assumption is correct that in your patch playback and loop
>> lengths are predefined, you could simply play the portion of the file
>> that exactly fits into a multiple of your metro period. You should then
>> use the bang from metro to retrigger the start of the playback. 
>> 
>> Roman
> 
> 
> 
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> 
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list