The question might be stupid,cause I am using processing with libpd. Libpd is a library that makes program languages and compilers read pd-patches.
So, I tried to make a sample based synthesizer.
To do that I used [soundfiler] to load multisamples in many arrays. For every organ I used from 12 to 20 arrays --> notes. Missing notes were created by shifting the existence arrays/notes using [e_pitchshift ] (rjdj library i think).
Anyway I used the message
[read -resize -maxsize 1e+06 note.wav arrayNote (
|
soundfiler

and i trigger the notes to play by a [select 22 23 ...midi_pitches..] to trigger [tabplay~ ] 's and inlet into select the midi pitches.

I tried to load 9 of these sets - meaning about 150 samples to 150 arrays. Its sample was about 550KB and 6 seconds.

The program was too slow. So I tried and delete all organs but one.
With one organ my program runs fine.

The questions:

1. Was it libpd, that couldn't handle the patch requirements or was it the patch too heavy from the beginning cause couldn't handle the samples?
2. If it was the second from prev. question, I was mistaken by trying to load -too many samples? -too big samples? -both?
   Or did I make wrong in this message arguments? : [read -resize -maxsize 1e+06 note.wav arrayNote (

Is there a limit in how many or how heavy samples can pd handle?

(Running in mac book snow leopard)

can you post your patch?

it sounds to me like the array resizing might be the culprit. but also, loading 150 soundfiles in ANY software is going to take quite a bit of time.

there are probably some ways to speed it up a but for you, though.

This is it, with its libraries. Just let you know, wherever there is a [recive ] object (not [r $0-mplampla]) , it takes data from processing. And also processing takes back the tables with the waves of every "sound processor unit" (eg. filter etc).
The tables are loaded at the subpatches atthe right side of the patch (trobone, violin,trumpet,etc).
I didn't include the multisamples folder cause it's 50MB.

What i have done so far (in another patch, not this), is to delete the bass and write ex. the 3 different trumpets not to 3X15=45 tables but since every time you choose what trumpet you want, write trumpet1 to 15 tables,and if choose trumpet 2, overwrite these tables with the new samples.

This don't crashes the patch sound,but when select to change organ (overwrite the tables), there is some damage.

oops, doesn't look like the file attached properly.

but also, even without posting it, here's another suggestion: you can probably get quite decent sounds by only using 1 or 2 samples per octave.

i think you will get quite bad sound quality using [e_pitchshift , too. It would be better in my mind to use [tabread4~] triggered by [line~] and then you can change the speed of file playback. Of course, that gives you faster playback at higher pitch, but should be better quality sound. This is how most samplers did multi-sampling back in the 90's, when memory was a concern.

Also, another suggestion. If you are just going to use tabplay~ and playback at normal speed, you MIGHT even be able to get away with not preloading samples at all, and just playing them directly off hard disk with [readsf~ ]. Not sure how well it will work with multiple notes at once, etc, but maybe give it a try.

i use tabplay~ with 88 tables and about 250 mb samples
of piano sounds and 24 voices without any problems.
(it takes about 3 seconds to load though). the cpu load is
hardly noticeable. i suspect the pitchshift is more likely the reason
for any overload, or perhaps very low memory, on a mobile
device for example. (pd stores all sample as 32 bit float
internally)

playing with readsf~ should work, but it might be necessary to
preload the beginnings of the samples into memory,
and crossfade after the first 64 ms or so. this might be worth the
effort if you want to quickly switch between sounds in a huge library,
without any interruptions of audio output.