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 said:

ok I noticed strange behaviour
when the track arrive to the end and stops (all good here) it won't start from the beginning if the next press is less then the time of the pause-timer. is this possible to fix?

Yes, it's possible.

[play~] is based on Max/MSP's [play~] object (from the cyclone library, which is not about storms, it's "CYcling-74 CLONE") -- I think you had said you used Max before? So you might be familiar with play~'s right-hand output, which puts out a bang upon stop.

Here it's perhaps a bit lucky -- it does not bang upon pause. (This isn't clear from the help patch, but I tried it.)

So when you get "bang" out of this outlet, you can use that to set a storage variable to restart.

But... actually it will take less time if I just send some screenshots. If I try to explain it and you build it, I guess it will be days of back-and-forth fixing problems.

23-0219-play-control.pd

I think that will do it... to be honest, this got a bit trickier than I expected... stupid little things which, two years ago, I wouldn't have known how to handle.

But at this point, I'm going to have to stop. I've already spent too many hours on this. At this point, you'll need either to handle remaining problems on your own or someone else can step up.

hjh

@KMETE Maybe you have solved it....?
Here a different approach..... nearly correct..... no time to check it thoroughly today.
I am sure that it fails on the pause/replay condition once the track has reached its automatic 60 second stop...... but it might be easier to follow than your previous approach.
Apologies for the [pipe]...... the order of operations rapidly becomes a nightmare.....
cart_wav_simple_mod.pd
Some things can be simplified.... and a lot of bangs and number boxes are only there for checking and understanding what is going on.
All vanilla I think.
David.

@whale-av I solved it in "ugly" way. I left loop 1 message and I'm using a timer to count the time of the audio playing and when it is bigger then the audio file length it will send off message to the sf-play~ object. the only issue I'm facing is a delay of few ms in the stop time so sometime you hear a brief moment from the beginning of the file. I will upload this solution once I will be at my personal computer.

@ddw_music Thanks for your hours and time! I will manage from here!

@KMETE said:

I solved it in "ugly" way. I left loop 1 message and I'm using a timer to count the time of the audio playing...

I'm curious though, did my last version work or not work for you? Because I did actually fix it for you but never heard back ... it now goes "pause - resume - pause - resume - (many times) - pause" and after it hits the end, "start 0 xxxxx xxxxx"

As for "all vanilla," there are trade-offs. readsf~ assumes that the system sample rate matches the file's sample rate -- not a problem in many cases, but worth noting. (IMO this is a gap in Pd's functionality -- in SC, I can VDiskIn.ar(numChannels, bufnum, BufRateScale.kr(bufnum)), and Max 1/ automatically compensates and 2/ has an "srate" message to sfplay~, but in Pd vanilla, you're stuck.)

tabread4~ couldn't handle 20 minutes of audio (but cyclone/play~ keeps a double precision phase, so it's fine for big files).

However, cyclone/play~ doesn't handle a mismatch between file and system sample rates -- which is why I made those abstractions. IMO you should be able to say "play at the file's normal speed" and get normal speed, regardless of the system's sample rate. My abstractions work that way. tabread4~ can, but you have to do the math yourself, every time. cyclone/play~ and readsf~ don't handle it at all. So I guess it's a matter of whether you're more interested in the vanilla functionality as given, or in a functional spec that works properly.

hjh

@ddw_music said:

I'm curious though, did my last version work or not work for you? Because I did actually fix it for you but never heard back ... it now goes "pause - resume - pause - resume - (many times) - pause" and after it hits the end, "start 0 xxxxx xxxxx"

I missed that part yesterday..! (long day) . I check it and is working as expected!!! thanks for that.
Only one small issue I can solved with [onebang] is that the right outlet of play~ outputting many bangs at end instead of one and that could make problems(?)

@KMETE said:

Only one small issue I can solved with [onebang] is that the right outlet of play~ outputting many bangs at end instead of one and that could make problems(?)

I noticed that and logged a bug with cyclone for it.

However it won't cause a problem here.

There is a big difference between hot and cold inlets. A hot inlet produces a result at an outlet: 50 bangs to a hot inlet = 50 results. But in this case, the bang is sending a symbol only to a cold inlet. One message to a cold inlet = change in object's state, but no result. 50 messages to a cold inlet = change in object's state, but no result. So in this context it doesn't matter: the cold inlet will not produce redundant actions downstream because nothing will happen at the outlet.

hjh

@ddw_music said:

There is a big difference between hot and cold inlets. A hot inlet produces a result at an outlet: 50 bangs to a hot inlet = 50 results.

I really wish Pd was at least this regular--it would've been much easier for me to learn. [timer] is a counter example.

@jameslo said:

I really wish Pd was at least this regular--it would've been much easier for me to learn. [timer] is a counter example.

AFAICS [timer] does not break the rule about one input to a hot inlet producing one output.

It does put the hot inlet on the right -- agreed that this is a strange decision. Probably the only reason for that is that it's very common to request a value from the timer and immediately reset it. If the hot inlet were on the left, you would have to cross the wires coming out of the preceding [t b b]. So it's a bit prettier at the expense of regularity (kind of like irregular verbs).

But I didn't say anything about the position of the hot inlet -- only that the hot inlet, wherever it is, produces one output for one input. Admittedly I haven't been around Pd as long as some members here, but the only exceptions I'm aware of are [spigot] (where the user can explicitly disable output), and method calls sent to hot inlets (which may not produce output, e.g. set xxx).

hjh