Hello commuity,

Im currently busy with writing a sampler device playing a different sample (wave file) for different midi key pressed. (multisampler)

On start up the sampler has to load up to 88 (wave- ) files (where 88 is the maximal numbers of keys of a keyboard) which have to be put in to separate pd arrays. Currently I put 88 array with different names manually in a subpatch to load the samples into those arrays. This process is somehow cumbersome.

Does anybody know how to implement such a multisamplerbased sampler more elegantly.....?

Br Absalom

I've once made a samplemap which i still use. You can find it in somewhere in this thread:

http://puredata.hurleur.com/sujet-1414-randomly-loading-soundfile

It's still going to take some work to create the extra tables (you want 88 but the map contains only 30 i think). But once that's done, you can use the textfile to load different maps.

D.

Thanks for reply....

Is this the common way. to preload the samples all to different arrays and to have
them available later when needed for playing e.g. also in a polymorphic sampler?

Or can one use one array per voice and can reload the samples when ever a different key is pressed.

Latter solution seems not real time capable for my opinion....

Looking forward for help

Br Absalom

That's the reason why i created such a samplemap. When pd loads a sample the audio-engine halts for a couple of milliseconds. This is very audible and therefore rather annoying. Preloading is the only solution i know of (or at least that's the advice i've often got when asking the same question as you)...

i have tried using [readsf~] and [block~ 64 1 16] to do 16x upsampling (therefore loading the sample at 16 times its normal playing speed) and that worked ok in realtime.

the process is:

readsf~
|
tabwrite~

in a subpatch with the [block~ 64 1 16] object.

Hey matt, how do know the samplelength in advance to resize the table(s)?

when i did it, i think i just had a big enough table to start with.

but, you could use the [wavinfo] external too, that might be better.