Greetings,

I have constructed a little sequencer that I'm using to playback sample data that I've loaded. Currently I'm just using [tabplay~] to playback the audio stored in an array.

However, if I start playing that sample again before the first instance of the sample was completed, the remaining sound in the sample is simply ignored.

For example, imagine I have a sample that lasts a certain length of time: [---------]

If I play that sample back to back far enough apart, everything is fine:
[---------] [---------]

If I play that sample back to back close together, the first sample playback gets cutoff:
[-----[---------]

Whereas what I really want is something more like:
[---------]
[---------]

I imagine this is a common issue working in PD - can someone fill me in on the common solution? Is there some kind of audio buffer I should be using so that the the beginning of the second playback mixes in with the end of the first playback?

Thanks.

Matt

you just need to add more tabplay~ objects.

edit: well not JUST add more tabplay~ objects, but that's a start. First, you'll need to decide the maximum number of overlapped samples that can play at one time. Say, for example, 4. Then you need to make a system to rotate the triggering through those samples. Probably something like:

[f ]x[+ 1]
|
[mod 4]
|
[sel 0 1 2 3]

I could see that working if I had a bounded set of samples that might play in a given time, but based on the tempo, the number of necessary tabplay~'s would go up and down....in fact I'm not even sure what a max number would be but I could see 8 of them being necessary when the tempo is very high. Is this really how this situation is handled generally in PD?

I figured there would be an intermediate buffer or something so that the sample could just write a copy of itself to the buffer every time its triggered which would prevent the sample from getting cutoff by following triggers....

if you take that to its logical conclusion though, if you have 8 samples being triggered at once, then you have to have 8 (or at least 7) samples all writing and reading from buffers in realtime.

compare that to the approach of having just one sample table, and then 8 playback objects (tabplay~) and i think you'll see that the tabplay~ approach is more economical.

you can probably make it even MORE efficient, by putting each [tabplay~] object in its own subpatch, together with a [switch~] object. That way, the audio will only be calculated when the sample is triggered. The right outlet of [tabplay~] sends a bang when the sample has finished playing, so you can send that bang to a [0 ( message to turn switch~ off.

not sure if you really need to do the subpatch / switch thing if you're just using tabplay~ though. it probably doesn't make too much difference. However, if you were thinking to make pitched playback or something with [tabread4~] then it would definitely be worthwhile.

sorry for so many posts.

just to clear one thing up: because tabplay~ doesn't do any buffering, interpolation, or anything like that; it is really a very simple object. All it does is read from a table and spit out the sample values one at a time at audio rate. This means that it really doesn't use very much of your CPU resources to run. Even if you set up 10 of them, and 8 of them just stay dormant most of the time, you're not really wasting too much CPU power.

Thanks. I will give that approach a try. I'm just very surprised that there is not some centralized buffering approach to this problem.

I'll try to remember to post back when I get it working and mention if I ended up finding a more concise method, or if I just went with the multiple [tabplay~]s. I don't know very much about PD so I'm struggling with a lot of this stuff...

there may be some external that does it the way you suggest, i'm not sure. i don't use pd extended very much.

good luck!