@KMETE Cool! Using f and i boxes as variables is an essential technique.

Glad to hear there's some progress.

hjh

I thought I get it but still it is not working as expected.. very frustrating

I'm not at the computer now, but I would proceed by steps.

Sensor = 1 play/resume, sensor 0 = stop. Get this very simple specification working first.

Then start the timer on sensor = 0 and be sure that the timer is counting correctly.

Btw I think you can simplify this using the pd [timer] object. Why? Because you need to know the elapsed time only when the sensor was 0 but becomes 1. So there is no need to poll the time continuously. Sensor 0, bang to timer's left inlet, sensor 1 to timer's right inlet.

Then:

• If the sensor goes to 0, the playback rate should change to 0 (pause).
• If the sensor goes to 1, the playback rate should change to 1 (play again).
• Note that these two behaviors do not depend on the timer at all!
• Then, also at the moment when the sensor becomes 1, if the timer shows a long enough period, then you would also send "all" to the left inlet.

hjh

@ddw_music said:

I'm not at the computer now, but I would proceed by steps.

Sensor = 1 play/resume, sensor 0 = stop. Get this very simple specification working first.

this is one of my main issues. the sensor should resume if 1. but when the patch is first loaded the message "resume" is not starting the playback

here is where I got so far. It seems to work ok but in my way. I would be happy if you don't mind to share the way you think is the correct way.

sfplay~example7.pd

edit: the part on the right end side is to avide clicks when audio is resuming/pausing. when 1 start the audio then start the line envelope. When 0 start the envelop to zero from 1 and only then pause the audio

@KMETE said:

this is one of my main issues. the sensor should resume if 1. but when the patch is first loaded the message "resume" is not starting the playback

"resume" is not a valid message for sf-play~. It won't do anything in any context.

here is where I got so far. It seems to work ok but in my way. I would be happy if you don't mind to share the way you think is the correct way.

If I can do it in 15 minutes tomorrow, I could send it. I really don't have more time than that.

Also good to see that you added an envelope for pause and play -- that's necessary!

hjh

@ddw_music said:

"resume" is not a valid message for sf-play~. It won't do anything in any context.

It seems that resume indeed resuming playing after pausing.

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.