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?

can you please share the above example patches?

I did it in my patch. although I loaded a stereo file, I can here only the left channel but when looking into the array define $1_LEFT and array define $1_RIGHT both are seems to be empty.

@KMETE

OK, here are a couple of test patches. Be sure to save them in the same directory with the audio files (to test relative-path file access).

The first one checks the basic behavior of soundfiler. If neither of these tests is OK, then nothing is going to work.

I'm suggesting this test because -- in your original patch, you're using soundfiler with a relative path "G2001.wav" and this is OK. Using [stereofile], you've tried a full path "/Users/...../G1001.wav" and this was not OK. (Also known is that both relative and full paths are fine on my machine.)

Experimentally, that's two variables: soundfiler vs stereofile, and relative vs full path. So it's impossible to say which one of those causes the problem, with the available information. To figure that out, we have to test basic soundfiler usage with both types of path.

test-1-2.pd

Check the Pd console window for "no such file or directory" errors, and copy/paste those errors into your message.

One possible issue here is non-ASCII (non-English) characters. The relative path "G1001.wav" consists entirely of ASCII characters, but based on your first screenshot, I might guess that part of your full path could include characters outside of the 0-127 ASCII code points. I've seen Pd choke on this before. I thought this was fixed in recent versions, but maybe there are still issues in Mac?

Second file tests relative vs full paths with stereofile.

test-3-4.pd

Last -- I added a [print] object into one of the abstractions to verify the "read" message (locally, you don't have this): "read -resize -skip 0 test-audio.wav test3_LEFT test3_RIGHT" -- it's fine.

Last last -- are you using [dac~ 1 2] or something else? The ezoutput~ in my demo patch routes to 1 and 2. If you are using different dac~ channels, this could be another reason why you're hearing left only. (I assumed that you know your studio's channel layout and that you would substitute an appropriate output object.)

hjh

Thanks I will take a look asap.
One question I have in the meantime - Is it possible to load and play aif files? or only wav files?

@KMETE aif is supported.

Couple of hints:

• [soundfiler] help opens with an example read message "read ../sound/bell.aiff array2".
• Within the same help patch, [pd read-write-flags] lists available formats: -wave, -aiff, -caf, -next (note this is not the file extension -- *.aif should work too).

hjh

What am I missing? I have placed the G1001.wav file in the same folder as the pd files and it still says no such file

I suggest connecting bang and [openpanel] objects to the read message and replacing the filename with $1 and find the audio file that way, eg.

[bang(
|
{openpanel}
|
[read -resize $1 left right(
|
[soundfiler]

@KMETE said:

What am I missing? I have placed the G1001.wav file in the same folder as the pd files and it still says no such file

I have no idea... at least know we know it is soundfiler's fault, and not anything wrong in my abstractions.

Which version of Pd are you using? Help -> About Pd

I ask because I saw bugs in the past with non-ASCII characters in paths. You have some Hebrew letters in the file path. Of course Pd should handle this but... maybe it's broken here. I think it was fixed (or supposed to be) but maybe it wasn't fully fixed in Windows. We should confirm that and log it as a bug.

As a workaround you could name the project folder with ASCII characters. This is irritating but it could help.

Also now I see the problem with your full-path test. In Linux, the home directory is /home/username/...; in Mac, it's /Users/username/...; in Windows it should be C:/Users/username/... but you used the Mac format, in Windows, which naturally won't work.

hjh

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