I have the following patch:

What I'm trying to do with out success is the following:
when sensor is pressed once (transient from 1 to 0 ) the audio will start playing. when sensor is pressed once again (transient from 1 to 0 ) the audio will pause (so far so good).
If the pause is less then 5 seconds the audio will resume from the same point. if the pause is more then 5 seconds the audio will start from the beggining.
What I am trying to add is if the audio is playing more then 60 seconds the audio will stop and will back to the beginning of the file (so when pressed again it will start from beginning).

How can I do it?

talk.pd

@KMETE

What I am trying to add is if the audio is playing more then 60 seconds the audio will stop and will back to the beginning of the file (so when pressed again it will start from beginning).

Do you mean like this?

• Pause >= 5 sec:
  • Next play should always start from the beginning
• Pause < 5 sec:
  • Last audio play time >= 60 sec: play from beginning
  • Last audio play time < 60 sec: resume

(It's really helpful to make a tree, or a table, describing the cases. If you just write sentences, it's very easy to overlook patterns.)

One pattern you can see from this is that the "pause >= 5" branch is easy: always from the beginning. So the "all" is fine.

But the "resume" message needs to be either "resume" or "all," depending on the last play duration. The last play duration is measured at the time of the "off" trigger.

This is a common pattern in patching, which has a standard solution: You need a changing message to be sent later, where the contents of the message are determined earlier based on some condition. (When the user lets go of the sensor, you determine at that moment how the next "on" will behave.)

For this, you need:

• A storage object. One of the messages is a list, so, use [list store].
• The "off" trigger sets the value of this storage object using its cold inlet.
• The (later) "on" trigger bangs the hot inlet.

Should be something like this:

1676400706585-talk.pd -- EDIT: but I just realized there's a mistake in here, the [r nextr] should be [r $0-nextr] and then the message-sends to that name should change to a real [s $0-nextr] instead of the message-box shortcut. I can update the patch later but I don't have time right this second.

This usage of a storage object is a pattern that's useful in thousands of contexts -- took me forever to figure it out (which reflects a pedagogy problem).

hjh

Updated to include $0 in the send/receive pair: 1676400706585-talk-b.pd

hjh

Do you mean like this?

Pause >= 5 sec:
Next play should always start from the beginning
Pause < 5 sec:
Last audio play time >= 60 sec: play from beginning
Last audio play time < 60 sec: resume

Exactly.

(It's really helpful to make a tree, or a table, describing the cases. If you just write sentences, it's very easy to overlook patterns.)

You are right. I will remember that for future

@ddw_music Thanks for your time!
I have try that but the problem is that when I press first time it play it at next press it will pause and at an additonal press it should resume but it won't do anything

if to be more precise:

Pause >= 10 sec:
Next play should always start from the beginning
Pause < 10 sec:
Last audio play time >= 60 sec: wait pause time(count till 10) : if next press < 10 sec - resume; if not (press > 10 sec) start from the beginning.

if audio file is arrive to end do not loop rather start from beginning at next press.

@KMETE said:

@ddw_music Thanks for your time!
I have try that but the problem is that when I press first time it play it at next press it will pause and at an additonal press it should resume but it won't do anything

I guess you must have tried something similar to my suggestion, but not exactly the same...? Hard to say because you didn't post that version.

What I explained yesterday is still correct: upon an off trigger, you need to choose the play message contents for the "short pause" branch and save them in a [list store].

I'm on a couple days holiday and not quite inclined to open pd until I get home... any other takers?

hjh

Yes I have try something looks like this:

blue outlet is connected to uzi that will send 1 then 0 to the sensor toggle on off. so is immitate like someone has paused to file.

@KMETE said:

Yes I have try something looks like this

That's nothing like what I suggested.

Go back and re-read my edit to your patch. I attached it in an earlier message.

You need the "resume" message box to be either "resume" or a "start from 0" list. Currently you have hardcoded "resume" for both cases (played for < 60 sec and >= 60 sec). I explained a way to not hardcode this value, but you haven't done it.

hjh

Here, I've distilled the trigger and timing logic -- should be easy to re-add sf-play2~ etc. (and substitute the real play-duration in place of "xxxxx" in the messages).

23-0217-timed-toggle.pd

Checking the 4 cases:

Played a long time, then paused a long time:

toggle-changed: 0
last play-time was: 2997.33
long last-play: 2997.33
list-store has been set to: 0 xxxxx 1
toggle-changed: 1
pause-time was: 2348
LONG-PAUSE PLAY MSG: 0 xxxxx 1 -- started from beginning, OK

Played a long time, then paused a short time:

toggle-changed: 0
last play-time was: 3250.67
long last-play: 3250.67
list-store has been set to: 0 xxxxx 1
toggle-changed: 1
pause-time was: 1092
SHORT-PAUSE PLAY MSG: 1092 0 xxxxx 1 -- even though it's a short pause, it starts from the beginning, OK

Played a short time, then paused a short time:

toggle-changed: 0
last play-time was: 1297.33
short last-play: 1297.33
list-store has been set to: symbol resume
toggle-changed: 1
pause-time was: 556
SHORT-PAUSE PLAY MSG: symbol resume -- OK

Played a short time, paused a long time:

toggle-changed: 0
last play-time was: 1553.33
short last-play: 1553.33
list-store has been set to: symbol resume -- short play time planned to resume, but...
toggle-changed: 1
pause-time was: 2125.33
LONG-PAUSE PLAY MSG: 0 xxxxx 1 -- the long pause time overrides "resume" and it starts from the beginning, OK

I'd really suggest to add sf-play2~ to this framework, rather than replacing chunks of it with over-complicated counter mechanisms which you don't need (timer measures time more efficiently).

hjh

@ddw_music said:

(and substitute the real play-duration in place of "xxxxx" in the messages).

Thanks for that. How ever I couldn't make it work yet.
Do you mean replace it by the real duration of the file like this?

@KMETE said:

Thanks for that. How ever I couldn't make it work yet.
Do you mean replace it by the real duration of the file like this?

Almost... It should not be "0 $2 1" -- it should be "0 $1 1"

Actually I'm quite baffled why you changed this. As I recall you did it correctly in the patch you uploaded earlier -- so you knew the right way, but then randomly changed a digit and broke it.

What is the result of getvalue? It's a single number.

What does $2 mean in a message box? It means to substitute the second value from a list.

Are you providing a list with at least two values? No... It's a single number. So the $2 is undefined and should be expected to fail. (And I think you knew that, but just perhaps working too quickly.)

Oh and I almost missed this -- getvalue needs a bang in the left inlet -- you're putting in a number, which it will reject. The reason for getvalue is -- if you use [value] directly and accidentally put a number into the left inlet (which your patch is doing), then it will overwrite the value and you will lose the true audio file duration. This is bad. getvalue protects against this, but you'd need to read the error message and add a "bang" message box.

hjh

I change the following:

Still the patch isn't working. What am I missing?
when I first press the toggle it starts. when I press again it stops. all good . When I press again to start it won't start.

talkC.pd

maybe it related to that error:

play~: no method for 'symbol'

@ddw_music said:

Played a long time, then paused a short time:

that scenario should resume the playback and not start from the beginning

so basically there is two variables shortTime for counting time when audio is not playing and longTime for counting time when audio is playing.

TrackTimeAudioPlaying;
shortTime = 5 sec;
longTime = 20 sec;
audioPlaying = True;

if TimeAudioPlaying >= longTime
pause track;
if next press < shortTime:
resume track;
if next press>shortTime:
start for beginning.

assuming a situation of long track of 20 minutes.
What I'm trying to do is that when someone press the button the track will start playing. if he press again the track will pause and a counter will start. if he didn't press again within 10 sec the track will start from the beginning at next press, if he did press the track will resume.

after 30 sec of track playing without any press it will pause. if next press is less then 10 seconds since the pause it will resume, if next press is after 10 seconds it will start from the beginning.

@KMETE

play~: no method for 'symbol'

Ohhhhhh... this. The no. 1 most irritating feature of Pd... sometimes you need to mark a leading symbol with the keyword ("symbol" or "list") and sometimes you don't.

Here, the keyword is needed before [list store], but it needs to be removed before [sf-play2~]. I always forget this.

that scenario should resume the playback and not start from the beginning

But this wasn't the functional spec you gave before (at least as it appeared to me).

In the first post of this thread, you said: "What I am trying to add is if the audio is playing more then 60 seconds the audio will stop and will back to the beginning of the file (so when pressed again it will start from beginning)."

This looked like you want LONG-PLAY always to go back to the beginning... but now it seems that isn't what you wanted. Quite difficult to build a patch when the rules are changing, or not communicated clearly.

I also find this a bit confusing: "assuming a situation of long track of 20 minutes... after 30 sec of track playing without any press it will pause."

If you have 20 minutes of audio, why do you want it to stop playing after 30 seconds? In that case, wouldn't you just load 30 seconds into memory, and then use the entire contents in memory (not looping)? At 44.1 kHz, 20 minutes stereo is about 400 megabytes... I hope you're not loading 400 MB into RAM only to want to play 10 MB of that.

So that's one way to stop automatically after x seconds -- simply don't load audio that you don't plan to use.

Otherwise, if you want it to stop playing after x (milli)seconds automatically, then you need [delay].

When you start playing, "bang" the [delay 30000]. At this point, if nothing else happens, then [delay] will output a bang 30 seconds later, and you can use this to stop playback.

If the sensor triggers during that time, according to documentation, you can send a "stop" message to the [delay] and it will cancel the 30-sec later output trigger.

So: [timer] measures the time between actually-occurring triggers (two triggers, reset and measure --> one result). [delay] produces a trigger later (one trigger --> add one result).

hjh

@ddw_music said:

I also find this a bit confusing: "assuming a situation of long track of 20 minutes... after 30 sec of track playing without any press it will pause."

The idea that it gonna be long track of conversation as part of an installation. it could be that someone will start the track and then go away. I don't want it to run all the 20 minutes so the audio will run in chunks of time. every lets say 60 seconds (not 20) the audio will pause and if someone will press it again within the short time frame (its say 10 seconds) it will resume. if not it will be start from the beginning at next press.
I hope this is more understandable. sorry for the confutation.

edit. I added the trim which helped but I see now the audio in not pausing after the long time variable. I have set the number 20 from outside so it should pause after 20 seconds of playing strait and it did not.

@KMETE

The idea that it gonna be long track of conversation as part of an installation. it could be that someone will start the track and then go away. I don't want it to run all the 20 minutes so the audio will run in chunks of time. every lets say 60 seconds (not 20) the audio will pause and if someone will press it again within the short time frame (its say 10 seconds) it will resume. if not it will be start from the beginning at next press.

OK, so the "playing" and "paused" timers actually have no interaction -- there are just two rules:

• Play: Stop when user stops, OR after x seconds
• Pause: If paused a short time, resume; if paused a long time, restart (here, btw, the [list store] idea was based on my mistaken understanding that the "resume" vs "start over" behavior depended on the duration of the last segment that was playing. In fact, it depends only on the last pause duration -- which is determined at the moment of play -- so it's a simple [timer] --> [moses] and done)

Here's my solution. (Screenshot omits a [loadbang] --> "loopx 100" -- the patch for download is complete.)

23-0219-play-control.pd

[pd play-timeout]

[pd pause-timer]

One other thing I'd like to call attention to is the liberal use of [pd] subpatches. When things get complicated, it's useful to encapsulate parts of the logic, for two reasons:

1. Less stuff in the window to get confused about. (I've seen students think "eh, a busy window is no big deal" but... if you have 10 times as many inlets/outputs visible, that's a hundred times more chances to make a wrong connection.)

2. Programming works better and goes more smoothly when the flow of information is restricted to a smaller number of paths whose meaning can be controlled and understood. It's much much easier to deal with the pause-timer and play-timeout when they are in their own windows, with only the necessary information coming in via inlets.

hjh

I do really sorry for all the confusion. My English is not my first language and I have hard time apparently to explain my self and how I want the system to behave. I will try to explain again and I hope to be more understandable

person press track is start to play if 60 seconds pass the track is paused. if since that pause no one is pressing within 10 seconds - track will start from beginning on next press. if someone is pressing within 10 seconds - track will resume from the point of paused.

if track is pressing and pausing before 60 seconds has passed - again next press should start the track from the beginning if 10 seoconds has passed, if not (press was within 10 seconds) track will resume.

when track is arrive to it ends it will not loop.

One reason I needed to use the loop 1 message is that the track was always paused for some reason before it ends when no in loop mode.

ok so you patch you share is doing ecsatly what I meant but there is one problem I also faced before. If the loop is set to zero meaning - no loop; for some reason the track will not play until the end rather will always stop before finished. Is it a bug in the sf-play~ abstraction?

@KMETE

If the loop is set to zero meaning - no loop; for some reason the track will not play until the end rather will always stop before finished.

Could you explain a little more how you are arriving at this conclusion?

If you have 20 minutes of audio, and the patch will play up to 60 seconds at one time, then:

• If playback resumes at 18min 59sec, I would expect playback to stop at 19min 59sec -- before the end of the file -- this is correct behavior based on the 60-second timeout that you specified.

• If playback resumes at 19min 01sec, I would expect it to play to the end.

So I just want to confirm that you are certain that you are actually advancing through at least 19 minutes out of the 20 minutes before observing the problem. Because... if you're resuming playback anytime earlier than that last minute, then playback is not expected to reach the end of the file (and early-pause would be the correct behavior).

hjh