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!

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.

That's great info Maelstorm, thanks!

About switch~...

If I send a 0 to a switch~, does that subpatch stop consume CPU?

Johnathan Noé and I are working on a multieffect patch. We need to switch between different effects (a lot) to select one, but we can't use only a [*~ 0] to mute all the others... because they all would consume CPU all the time. If switch~ prevents to consume CPU, it would be the solution. Does it?

if it's your audio processing that needs cpu time, [switch~] will help. If it's your message processing that hogs the cpu, [switch~] won't help.

I think that it is audio processing... but I don't know what is "message processing". Can you explain it to me? Thank you very much.

In PD, audio usually goes through thick cables and tilde objects (like [*~]) and messages go through thin cables and non-tilde objects (like

• ). [switch~] only turns off audio processing.