@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