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?

I will check it late on my mac computer. for the moment I'm not on my computer, so I don't want to waste much time on it now as I think it will work on my computer.
For the moment I'm using your help file patch which is great. Your abstraction is so much more easy to use then from my patch I shared in the beginning.

what I'm trying to do is the following -
I will have 8 different sound files. Each sound file should be in a individual sf-play2~ object.
I will have data from 8 diffrent sensors I'm reading via arduino. Each sensor will report 0 or 1 (if sensor is pressed or not) alongside with analog data of numbers between 0 - 1023.
What I would like to do is that when I'm reading 1 the audio file will play, when reading 0 the audio file will pause . if 1 is held and the audio file arrived to it ends it will continue from the beginning. (loop 1) . I will also have a clocker to report how much time has elpased since sensor is 0. If more then x seconds the audio file will go back to beginnnig so next time sensor is held (1) it will start from the beginnnig.

here is my try with your abstraction.
the green part is to imitate the on off from the sensor. the blue is the analog data from sensor.
the orange part is my try to make a clocker that will start count when sensor is off. The yellow part is for small envelop to avoide clicks when audio is pause and resume.

How can I make the audio file go to the beginning when the orange part is reporting a bang (that time was elapsed) ?
Also - I'm not sure if the yellow section is working. Meaning if it is indeed making an envelope on every pause and resume ? Is that possible?

sfplay~example.pd

Thanks!

edit: the scale of the sensor should be inverted. 0 1023 0 1

edit 2: how can I make the sf-play2~ go back to the beginning of the audio file without starting it immediately?

edit3: how can I load the file to the sf-play2~ object without starting it? if I don't press "all" message it won't load the file. I would lik the file to be loaded to the beginnnig, but to start and play only when receiving data from sensor on off. for the moment if I'm not pressing all message the file won't play.

@KMETE said:

edit 2: how can I make the sf-play2~ go back to the beginning of the audio file without starting it immediately?

If sf-play2~ is stopped, then it is silent.

If you "go back to the beginning without starting it" then... it is still silent.

So IMO it's a meaningless distinction "in the middle without playing" vs "at the beginning without playing" because in both cases, it's not playing = no sound = no difference to the listener.

It is playing from memory so "all" will restart from the beginning instantaneously. There is no need to pre-rewind the file.

edit3: how can I load the file to the sf-play2~ object without starting it?

sf-play2~ doesn't load anything. stereofile does that.

So you just load it into the stereofile, and do not trigger sf-play2~ until you want it to sound.

hjh

The issue is that in order to pause the audio and not start it from the beginning I need to send the message pause and the medssage resume to start it from the point of pausing.
When the patch is loaded and i'm pressing resume when sensor is 1 it won't start the audio file.

I will try to explain my self better (sorry, as my English is not my first language)

When sensor is 1 audio file is playing. when sensor is 0 - audio file is pause . If sensor is 0 more then x seconds - audio file will start from the beginning at the next time sensor is 1.

I did not mange doing so with the messages in my patch

@KMETE said:

The issue is that in order to pause the audio and not start it from the beginning I need to send the message pause and the medssage resume to start it from the point of pausing.
When the patch is loaded and i'm pressing resume when sensor is 1 it won't start the audio file.

Hm, sf-play2~ is really meant for playing segments.

I have another abstraction, sf-varispeed2~, where you can pause by putting 0 in the middle inlet, and resume by putting 1 in (and reset to the beginning by "all" to the left inlet).

hjh

my above explanation of needs is not possible to implement with your sf-play2~ abstraction?

@ddw_music said:

@KMETE said:

The issue is that in order to pause the audio and not start it from the beginning I need to send the message pause and the medssage resume to start it from the point of pausing.
When the patch is loaded and i'm pressing resume when sensor is 1 it won't start the audio file.

Hm, sf-play2~ is really meant for playing segments.

I have another abstraction, sf-varispeed2~, where you can pause by putting 0 in the middle inlet, and resume by putting 1 in (and reset to the beginning by "all" to the left inlet).

hjh

my problem with all message is that it will also immediately start the audio file. I need it to bring the file to the beginning without starting it immediately rather on the next 1 from sensor.

I have try using the sf-varispeed but I have some bugs and can't make it work as needed.

sf-varispeed2~example.pd

@KMETE said:

my above explanation of needs is not possible to implement with your sf-play2~ abstraction?

No... If it were possible, there would be no reason to suggest a different object.

my problem with all message is that it will also immediately start the audio file. I need it to bring the file to the beginning without starting it immediately rather on the next 1 from sensor.

You don't have to bring the file to the beginning until the moment you're going to play it.

Really, here you are creating a problem that doesn't exist.

• If you want to start it playing from the beginning, use the "all" message. There is no need to reset the position until the moment you want the sound.
• If you want it to pause/resume, use 0 and 1 in the rate inlet.
• If it is paused (rate 0), and you want to restart from the beginning, send 1 to the rate inlet and "all" to the left inlet at the same time and you do not have to do anything extra before this moment.

I have try using the sf-varispeed but I have some bugs and can't make it work as needed.

The screenshot looks more complicated than needed. The uzi sel thing at the bottom, totally unnecessary (and reads a bit nonsense to me, there's no need to start play and stop immediately).

Unfortunately I don't have time to digest all of the requirements just now... My suggestion is:

1. Start with the functionality: Make buttons/toggles for start, stop, pause, resume. Implement these in the most simple way possible.

2. Only after all of these are working, then connect your sensor etc interfaces.

Things get very confused when you're trying to do interface work at the same time as working out the program logic -- it may help you to separate these tasks.

hjh

@ddw_music said:

@KMETE said:

my above explanation of needs is not possible to implement with your sf-play2~ abstraction?

No... If it were possible, there would be no reason to suggest a different object.

my problem with all message is that it will also immediately start the audio file. I need it to bring the file to the beginning without starting it immediately rather on the next 1 from sensor.

You don't have to bring the file to the beginning until the moment you're going to play it.

when sensor is zero the timer starting to count. If time is elapsed it report a bang. That bang should bring it to the start position. How can I store that data and bring it to start the file from the beginning only when the sensor is ON again ?

I mange to doing so with the following. but I am using uzi...

@KMETE said:

when sensor is zero the timer starting to count. If time is elapsed it report a bang. That bang should bring it to the start position. How can I store that data and bring it to start the file from the beginning only when the sensor is ON again ?

Key words are "store that data." In traditional programming languages, you'd use a variable. In pd, there are [f] boxes.

Let's say the [f] should be 1 for reset, 0 for resume from old position.

"If time is elapsed it report a bang" -- this should send a 1 to the f box's right inlet.

When the sensor is on again, send a bang to the left inlet of the same f box and you will get the last saved status.

What I can't see from your description is what should reset the f box to 0. But in that situation, put a 0 into the right inlet.

hjh

I think I finally got it (?) when patch is load - a 1 is loaded into [i] right inlet. when sensor is first 1 it start to play the file. when 0 it pause. if 0 more then x seconds it will store 1 into right iled of [i] and will output it at the next time sensor is 1.

sfplay~example3.pd

@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