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?

Sound file usage is one of those things in Pd that really triggers me. All the pieces are there, but... sound files should be easy. They aren't easy.

For the sake of my students, a year or two ago I made a set of abstractions that do make sound files easy. (A couple of them use cyclone btw, so you would have to install that.)

https://github.com/jamshark70/hjh-abs

Using these abstractions, I can re-trigger a sound file easily in two ways.

• On the left, feed the "bang at end" back to trigger another "all" message. (The [spigot] is to make sure it really stops when you stop it.)

  • The loop will be quantized to the audio block size.

• On the right, enable crossfade looping in the player and just let it run.

  • The loopx message specifies the number of ms at the end to use for the cross fade, so the loop will be file_duration - loopx ms.

IMO the crossfade is better, to avoid clicks at the loop point.

23-0115-sample-loop.pd

(Note the comment at the top about stereo.)

Admittedly, this doesn't directly answer the original question about how to repeat the file using the design in that screenshot. But, if I'm honest, my answer is that I wouldn't do it the vanilla way, because I think the baseline vanilla objects don't provide a usable programming interface. If part of the problem that you're running into is that the object interfaces aren't usable, one solution is to use a different interface.

hjh

thanks for your replaying.
One big difference between your method and the design I am using is that mine is load the file to buffer and yours is reading from disk? that could be an issue if the end patch should contain 15 audio files ?

@KMETE said:

One big difference between your method and the design I am using is that mine is load the file to buffer and yours is reading from disk?

No, that's not true at all. If you look at the abstractions, you will see that they all use in-memory arrays. Just because the array is not displayed in the top level patch, does not mean that it isn't there.

hjh

@ddw_music
What I'm doing wrong for getting those errors?

it seems it can't load my file

@KMETE said:

@ddw_music
What I'm doing wrong for getting those errors?

Most of the errors are expected, if you're changing it from monofile to stereofile.

it seems it can't load my file

That's a real error though. As a test, you might try using exactly the same path with soundfiler -- the monofile and stereofile abstractions don't do anything funny to the path. They just pass it to soundfiler.

Edit: I found in the past that if you want to use a relative path (as in your original patch), the patch location has to be "declare"-d as a path: [declare -path hjh-abs -path .] -- this strikes me as a rather silly quirk of Pd's search path system, but the declare seems to handle it. So an alternate way might be to change the declare as noted, and use [stereofile brk G1001.wav] or other filename.

hjh

I manage to load a stereo file but I'm hearing only from left channel and not from the right channel

@KMETE said:

I manage to load a stereo file but I'm hearing only from left channel and not from the right channel

Is the file genuinely stereo? If you load a one-channel file into a stereofile, then you would get audio in the left channel only.

I just noticed in your original patch that you are loading the same file separately into the L and R arrays. You don't need stereofile for that... If the file is mono, use monofile.

As for the error in your screenshot --

The stereofile object creates two arrays, brk_LEFT and brk_RIGHT. (Or maybe it's a hyphen -- I forget, but it's not important.)

[sf-play2~ brk] looks for arrays brk_LEFT and brk_RIGHT.

[sf-play~ brk] looks for one array, brk (which would be created by monofile).

So you can't use sf-play~ with stereofile, and also can't use sf-play2~ with monofile.

You still have one sf-play~ in the patch, so make sure to change both of them. That will take care of the error message.

hjh

@ddw_music said:

@KMETE said:

I manage to load a stereo file but I'm hearing only from left channel and not from the right channel

Is the file genuinely stereo? If you load a one-channel file into a stereofile, then you would get audio in the left channel only.

Yes I'm sure its stereo file.

I load a stereo file into sf-play2~ but only audio is coming out from left channel

@KMETE said:

Yes I'm sure its stereo file.

Ok. Ctrl-click on the stereofile abstraction.

Inside there are two [array define] objects.

If you are not in edit mode, you can click on these and see a graph of the audio.

Can you check to be sure audio is loaded into both?

hjh

To clarify: Here, into [stereofile b1 ...] I've loaded a two-channel file, and into [stereofile b2 ...], a one-channel file.

Step 1. Open the b1 abstraction.
Step 2. (Don't enable edit mode) -- click on [array define $1_LEFT].
Step 3. Click on [array define $1_RIGHT].
Step 4. See that both arrays contain audio.

Step 5. Open the b2 abstraction.
Step 6. (Don't enable edit mode) -- click on [array define $1_LEFT].
Step 7. Click on [array define $1_RIGHT].
Step 8. See that the left array contains audio while the right array contains nothing.

[monofile] and [stereofile] pass messages to [soundfiler]... so you could test also like this:

^^ this is the correct way to load a stereo file into soundfiler (note, I didn't actually run it in this patch, hence the empty audio -- but this is the right method!). But your original screenshot doesn't do this. Your original patch loads the left channel twice (which is just wasting memory btw).

hjh

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