Hello All,

I am embarking on building a polyphonic sampler with maybe four or five voices, that would be triggered via drum pads, and would have mute group settings, like the old-school akai samplers.

I want to keep it easy on the processor, and so I want to just have maybe four voices, but play from a least 8 sound files, even better would be 16 or so.

In an old thread HD mentions the following:

@HD said:

You don't have to use a vline/tabread4 for every single sample. You just need to determine the max number of voices that you want to play at any point in time. For example, if you only want to play a max of 4 samples at any point in time, then you only need 4 sample playback subpatches. You can set it up so you load more than 4 samples into your patch, then just use a "set" message to change the buffer you're reading from. I can provide a simple example if you want.

This is exactly what I want to do, and I will set out to do it, but if anyone has an example of what HD was talking about back in 2009, I would love to see it. I will post what i get when I get it up and running.

All the best,
Leigh

i think if you look at the help file for [tabplay~] or [tabread4~], you'll find what you need

That's interesting information, especially the onset stuff with tabread4.

But my main question, which I should have put more explicitly, is whether I can have a 3 or 4 voice polyphonic sampler playing samples from a bank of 8 loaded sounds. Using a "set" message to change the array the voice plays based on which pad I hit. Sort of hot swapping samples. Instead of having 8 voices drawing from 8 different arrays, 4 or 3 voices playing from 8 arrays.

your original question was well understood.

and the answer IS in the help file for both tabread4~ and tabplay~ as well as probably all the table reading objects.

you can send a message [set arrayname(
to the tabread4~ object and that will set which array the object will read from.

so, for example, you have 8 arrays (or tables), named like:

array-1
array-2
array-3

etc

then, you can just send

[set array-1(
|
[tabread4~]

and that will tell tabread4~ to read from array1.

if you want to make it more dynamic, you do something like:

[3 (
|
[set array-$1(
|
[tabread4~]

in that case, the $1 is substituted by the float received in the inlet of the message, so it becomes "set array-3"

by sending different floats into the inlet you can switch between your different arrays.

just keep reading help files, and whatever pd documentation you can find, and it will all start becoming clearer.

what you're trying to do is an ideal project for getting to grips with the workings of pd. keep at it and you'll definitely succeed. of course, when you get stuck, that's what this forum is for.

good luck!

AH OK, thanks. I saw that they have the ability to receive "set" messages, but wasn't sure if it would work to set the array on the fly while triggering samples. This is good to know. Thanks again.

cool, hope you get it going.

one little thing to keep in mind perhaps: when you use the set message to switch between playback arrays, there is a high probability that you'll create a discontinuity in the output wavform, and get a click.

the usual way around this, is to ramp that voice's amplitude down to 0, over about 5ms or so. like this:

[0 5(
|
[line~]

then, by using a [delay] or [pipe] object, perform the switch,

finally ramp the amplitude back up to 1 , by sending [1 5( to the [line~] object.

the output of [line~] should go into one side of a [*~ ] object, and the output of your tabread4~ / tabplay~ object should go to the other side of the [*~]

Hello All,

I have been struggling a bit getting my sampler to work. I think the two sticking points are the adsr envelope and using tabread4~ object correctly. I have it set up as a 5-voice polyphonic sampler that uses 12 pads to trigger 12 different arrays.

But it's not really working. I think it's successfully handling passing the array name to the tabread4~ within the sampler voice objects, but somehow it's not all lining up. I went with the susloop~ object after another version using phasor~ that wasn't working with the envelope.

If anyone is willing to look at this and give me a pointer or two, I would be very grateful. It should be self-contained--the sounds are in a subfolder, and then gui is pretty self explanatory. If you don't have a midi controller, there are a couple of messages that send midi notes for testing purposes.

Here is the download.

All the best,
Leigh

i think you're going to have to isolate the problem a bit more. it's a big patch just to debug like it is.

OK, I will isolate it and re-upload a smaller patch. I believe poly is doing what it should be doing, so I can just make a single voice version and go from there.

Here it is, as stripped down as I could make it, and annotated as well.

Le voila

Best, Leigh

I should mention, there is definitely something going on with the envelope. I am printing out the values being sent to the adsr object, and I see that the peak amplitude is always being sent as zero--which is confusing to me. I am using a trigger to send the various parameters before I send the trigger.

you seem to have a heap of execution order errors.

your [unpack 0 0 0 0 0 ] will output values from right to left.

then your [pd env 0 0 0 0] is expecting to get the leftmost value LAST, to trigger everything in order.

this is not what happens, so some messages are sent in the wrong order.

you've been a bit too adventurous with this patch, without understanding execution order properly. you're actually not too far off, and i can see you know it's important as you have included the [ t b b b b ] object to try to get it right. but there are errors further up the chain with the [unpack] object that need to be addressed.

if i were going to debug this patch, i'd pretty much have to delete most of it and start again. that would be the easiest way, rather than unjumbling all the wires coming out of [unpack] and into [pd env].

also, don't expect [env~] to output the amplitude of an envelope. [env~] outputs the loudness of an audio signal. this means waveforms that go up and down 100's of times a second, usually. if you feed an adsr envelope into [env~] all it sees is a waveform not changing very much and tells you that the average amplitude is pretty much nothing.

Oh wow, I had the execution order of the unpack backwards. Thanks, you really helped me out with this info. When I get it working I will post it.
All the best,
Leigh

execution order is annoying at first, but quickly becomes second nature and you barely even have to think about it.