I have this patch that reading an audio file from buffer.
At the moment when it arrives to the end of file to will not start from beginning unless I reset it to start. or can I make it go to the start of the file if arriving to the end?

Here's how I would do it.

23-0118-pause-resume.pd

The [print] boxes show that it resets to the beginning only when the sensor was off for more than 3 seconds:

timer: 8129.33
reset: all
timer: 1130.67 -- too short, no 'all'
timer: 789.333 -- too short, no 'all'
timer: 4309.33 -- long enough, go back!
reset: all

It seems that resume indeed resuming playing after pausing.

Aha, OK, it turns out that cyclone/play~ does answer "pause" and "resume" (and sf-play2~ just passes those messages to cyclone/play~ -- I didn't implement them but they work, nice catch). So here's another (maybe more CPU friendly):

23-0118-pause-resume-2.pd

hjh

Thanks you very much. That is much clearer then my take.

why did you add 100 at the sf-play2~ object right after the array name au ? to start the file from the 100ms time and not from 0ms? why is that?
assuming I will need 9 of those patches. do you recomend me to create an abstruction? how I will be able to change each abstraction file name from outside the abstraction?
for the array name I could just add $0 at the end of the name. I'm not sure how I can change the name of the file from outside?

Thanks for all the help

@KMETE Abstractions have only one name..... e.g abstraction.pd
They are made "different" by arguments..... so putting [abstraction 1 woof] and [abstraction 2 lala] into your patch will use abstraction.pd with different value for [$1] and [symbol $2] within those abstractions.
You can then put a [receive $2] within the abstraction.
In the first that will receive from a [send woof] and in the second from a [send lala]
Using those sends you can send symbols like myaudio.wav into the correct abstraction.

You can remame arrays (wirelessly) with a message if you need to do that.....
[;
thisarray rename thatarray(
........from anywhere...... so even from outside the abstraction..... although $0 in the name will complicate matters...
David.

I have created an abstraction called sfplaypatch.pd

I gave a unique name for the buffer by adding $1 at the end.
I also write $2 instead of the audio file name. What I would like to do is to load a different name of the audio file for each abstraction.

sfplaypatch.pd

and here is my main patch:

pdMain.pd

how can I pass the name of the audio files from the abstraction itself?

ok, it seems to work just fine! the name I am giving to each abstraction after the abstraction name is indeed replacing the $2 sign inside that abstraction and therfore loading different audio file for each abstraction

@KMETE said:

why did you add 100 at the sf-play2~ object right after the array name au ? to start the file from the 100ms time and not from 0ms? why is that?

The sfplay2~ help patch explains:

Arguments:;
1 Table name (should match a soundfiler2 instance) - recommended to use [monofile] or [stereofile];
2 Envelope A/R time, default is 10 ms

The second argument (the 100) is the envelope attack-release time, NOT the playback start time.

In sf-varispeed2~ it's a little different -- when looping, it's the crossfade time.

I just realized, there is one mistake in both of my patches. I'm specifying a loop crossfade = 100 ms. To crossfade properly, it needs to subtract 100 ms from the file's total duration.

So, where you see "all" in those patches, substitute like this:

(In your abstraction, you have "stereofile audio$0 $1" which is fine -- but you'd need "getvalue audio$0dur" then.

Should be the same for the varispeed version too.

hjh

@ddw_music said:

(In your abstraction, you have "stereofile audio$0 $1" which is fine -- but you'd need "getvalue audio$0dur" then.

Should be the same for the varispeed version too.

hjh

what is that dur ? why is needed? it seems to work in my abstraction without your addition

@KMETE Requoting myself: "To crossfade properly, it needs to subtract 100 ms from the file's total duration."

Let's say you have 10 seconds of audio.

You want to loop it, with a 100 ms crossfade.

If you just use "all" then it will do this:

1. Start at 0 and play to 10 sec.
2. Loop back to 0.
3. At this point, for a cross fade, the step 2 audio fades in, and the step 1 audio fades out. But step 1 has already run out of audio.

So at that point, you don't get a cross fade. You get an immediate jump to silence (maybe with a click), and then a fade in.

It "seems to work" in that there is no error, nothing crashes, no major audio glitches. But it isn't crossfade looping.

The solution here changes it to:

1. Start at 0 and play to 9.9 sec.
2. Loop back to 0.
3. At this point, the step 2 audio fades in, and the step 1 audio fades out over the range 9.9 - 10 sec = clean crossfade.

But if you're happy without a proper crossfade, then by all means, do what you feel is best.

At this point, with apologies, I need to withdraw from the thread. I've already spent much more time on it than I expected, and the follow-up questions are becoming a bit like... not the best use of time. Like, I'm getting ready to shoot a YouTube tutorial on Pd external sync, and instead of working on those materials, I was explaining crossfading here. I think I need to strike a better balance.

hjh

@ddw_music Thanks for all your help and kind explanations! I have learned a lot.