long story short, one aspect of a patch I'm trying to develop requires being able to pause, playback, and loop multiple streaming files (or tables) in quick succession. For example: pause playback of file #1, file #2 automatically and immediately starts. . .pause playback of file #2, file #3 automatically and immediately starts . . . random event occurs, file #3 is paused and file #1 begins playback from where it was last paused, so forth.

Files are numerous and long. There are about a dozen and they are 5 to 45 minutes a piece. This amounts to huge uncompressed audio files, so a configuration involving [tabread4~] (which enables the development of refined playback controls, but only works well for short loops) won't work, and [readsf~] won't either, because i need to be able to pause and resume playback.

Any suggests?
Thanks!

How is that different from using [readsf~] ? It seems like it loads the file into ram when you send an "open" message, hence the delay. And in this scenario everything has to be pre-loaded.

Arrays have a hard-coded limit of about five minutes (at 44.1kHz), so they are inadequate for very large files. I've never done it myself, but I suppose you could split the file into several arrays using the -skip flag for [soundfiler], then use a single [phasor~] to read multiple [tabread4~]s by scaling it so that the beginning of the [phasor~] reads the first array, then the next part reads another array, etc.

It has been my experience that if you set the size of a table before loading the audio file you can load files over an hour in length (I haven't tested much beyond).

I just tested again using a 1hr wav of white noise (generated in audacity),

Interesting. I don't think I ever tried it by giving

No problem.

For those who don't know, you can resize a table with a message like so:

[; table_name resize 158760000;(

I like to set a max-size with a message like this, load a file into the table with [soundfiler], and then send the "total samples" output of [soundfiler] to another resize message to be sure there isn't any empty space after the loaded file.

great info everyone's got problems with this.
thanks

Here's a hasty example patch employing some of the above techniques:

http://puredata.hurleur.com/viewtopic.php?pid=18826#p18826

@pulsed said:

Hi
An easy way to pause [readsf~] is to put it in a [pd subpatch]
with a [switch~].
Send [switch~] a 0 to pause and 1 to continue.
Same for [writesf~] btw.
mvh

I need what hollywoodshower needed: to pause a song being played with readfs~. I tried with switch~ and it works (I don't understand what it internally does, but don't care), BUT... it makes a continous beep with the same frequency of the moment that was paused. I dont' want it.

The subpatch where I want to pause the music has a send~ to the main mixer (another subpatch). I have to mute the sound of this subpatch in the main mixer? Is there any other way to mute it?

Thanks!

You could have the pause button mute it right before it hits the [send~]

mute inside the subpatch at least 1 block before turning off the [switch~]

1 block? How? Using the delay?

Anyway... I found muting in the other subpatch is the best option. This is because it needs to be syncronized with another program (Blender), vía OSC. I can't have a delay... or I would can, but there is more code in Blender.

Any better idea is welcome.

Thanks!

you don't need to delay the audio, just delay the message to the switch. hopefully the attached patch demonstrates well enough.

i also included a 'better' version that uses [line~] to make a short ramp so you can avoid clicks in the audio when pause/playing.

http://www.pdpatchrepo.info/hurleur/switch-clean.pd

Thanks, Mod! I'll use the better version.

Hello. I'm also trying to do something similar: large wave files, pausing and resuming, readsf~, however, I need one more function. Is there any way as it's playing, to cause it to rewind a certain amount of time while it's paused?

I've connected two piano damper pedals to an arduino, to essentially control two toggle switches in PD, so that as I'm transcribing interviews from wave files, i can start and stop the recording with my feet, and not have to move the mouse, switch windows, blah blah, every time I need to stop and start the recording. So one pedal will play the file when the pedal is pressed down, and pause it while it's not pressed. The other pedal, I need it to rewind 2 seconds each time I press it, when I need to hear things again.

Any help would be wonderful! Thank you!

I ended up using soundfiler instead, and changed the second pedal so that it rewinds as long as you hold it down, not incremental 2 second jumps. It works, but sadly as the soundfile plays on, it sounds like it loses bit depth over time, so by the end it's very distorted. It's not so bad for a 17 minute file to transcribe, but it might get too distorted for longer files....

Yes, here too it loses bit depth
See attached patch (it's limited to 20 minutes)
Maybe there's a way to get around this?

http://www.pdpatchrepo.info/hurleur/largefileplayer.pd

I think the only way around it would be to split the file into multiple tables. You can do that using the -skip flag for [soundfiler]. So you'd have multiple samplers, and you'd have to switch between them as one ends and the other begins.

Another, albeit more hacky, way is to change the maximum table size in the soundfiler source code and create a modified soundfiler external.

see line 1123 of 'd_soundfile.c' :

#define DEFMAXSIZE 4000000      /* default maximum 16 MB per channel */

I've attached the external I've been using to load massive wav files, keep in mind that Pd stores tables with 32bit depth resolution so make sure you have enough RAM

I can't remember maximum size in that external but I think I just added a few zeros to the end

pd123's solution looks interesting. I've yet to test it out, but it seems weird that you'll be able to extend the limit like that. Could it be that it's sacrificing bit-depth for samples?

http://www.pdpatchrepo.info/hurleur/rj_soundfiler.pd_darwin

@Jwif said:

pd123's solution looks interesting. I've yet to test it out, but it seems weird that you'll be able to extend the limit like that. Could it be that it's sacrificing bit-depth for samples?

It works for loading the samples. The problem is with playing them back. Since the index of [tabread~] and such is an integer and 32-floats have 24-bit integer precision, once you start sending numbers greater than 2^24 you end up skipping samples. So you still can't really play back samples longer than about 6 minutes, 34 seconds (at 44.1 kHz) without running into errors.

You can play them back with [tabplay~], though. I think because it's just incrementing a pointer internally, so the precision isn't an issue.