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.
-
How to loop/reset an audio file to the beginning
-
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.
-
@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:
-
Start with the functionality: Make buttons/toggles for start, stop, pause, resume. Implement these in the most simple way possible.
-
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.
-
@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.
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.
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: allIt 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):
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.
