Loading multi-samples
Hi everyone. Moving my first steps in Max. I want to make a sampler where I can drop multi-samples, that is a folder with, for instance, 88 piano sounds, one per key. I found this tutorial (https://youtu.be/1rmliWiO0gI), which seems to do what I want, but it's 8 years old and doesn't work any more. For instance the player object he uses seems to have 3 IN and 3 OUT, whereas in Max8 it comes with 5 IN and 2 OUT, so I can't connect it like he does.
Can anyone pls. point me to a more recent tutorial or patcher that works in Max8?
Silvano
[dropfile], [folder] , [cycle], [prepend open], [buffer~].
[midiin], [midiparse], [route 1 2 3 4 5 6 7 ... 88], [play~], [*~], [dac~].
I would rather go with sfplay~ and definitely not 88 instances
of poly.
It would load much faster large samples,
and 32 voices would be just enough.
Even better 16 x 2 so that sustain pedal
with retrigger could be simulated.
@source audio for a sampler purpose, it's better to use RAM memory generally ; because it is less stress on the hard drive*, you have faster access to it, and there should not be a lot of memory usage (usually samples used in a sampler are very short). 88 voices of poly~ should not be over the top, especially since the ones that are not in use are inactive, theoretically, they don't use any cpu. (*it's less true in these days of SSD drives, but still stands : ssd has slower acces than ram, the point of ram is the fast access)
That been said there is a "samplor" package available through the package manager (from the max application, go to menu File>Show package manager ; then type "samplor" in search bar) which should also be what you want, @silvano. Now your task is merely one of choosing ;)
(about that "player" object in the video : the creator of the video used his own patcher which he named "player", the one that exist right now and which you are referring to is a video payer, and has no relationship with what you see in the video, despite having the same name)
@ vichug - more than 10 years ago most Software Sampers introduced hard disk streaming mode
cause Sample libraries became too large, and loading time unacceptable long.
Max had that option from the beginning.
Sfplay~ preloads small portion into buffer = RAM for fast start
and plays the rest from disk.
I still use on stage MacBook Pro from 2008 as hexaphonic Sampler
for Guitar To Midi, loading hundreds of Samples into sfplayers on the fly in no time.
Here is extracted loader :
buffer based sampler can't cope with that even on newest MacBook Pro with SSD,
it loads Samples too slow, changing sounds on the stage gets unusable.
ok for hundreds of gb that you change on the fly maybe it's better indeed, and for less gb it's maybe also better, but for 88 soundfiles it will not make any difference ; 88 voices of poly is fine. The other advantage of having them in buffer is if you want to use time-domain realtime treatments of the sounds inside the buffers (granulation etc)
while it for sure works, i would feel stupid to load samples into sfplay.
when you use a buffer you do not even need polyphonic layout for a piano.
you could just read all files into one buffer - every 200,000 samples one file - and replay that using index~ objects.
The point is that any approach would work, and that it depends
on the needs and simplicity.
I use polybuffer as well when it makes more sense for the task.
I just wanted to say that sfplay~ is a simple and efficient solution,
when no tohuwabohu, graining, stretching etc is needed, just plain playback.
And it gets mostly overlooked - by beginners in first place.
In addition - a serious piano sample
would need at least 30 seconds od stereo for each key,
and 2 - 4 velocity layers, otherwise mda piano or a rompler
would just do as well.
@ Roman I would feel rather stupid to have to make one big buffer
containing individual samples, calculate all the offsets etc etc.
Why complicated if simple is also possible ?
Let's count :
for sfplay it needs per poly voice:
1 adsr~
1 sfplay~
1 matrix~ for velocity / volume
Groove based:
1 buffer~
1 sig~
1 groove~
1 matrix~
-----
worse case index~ : would need samplecount per sample
calculating offsets etc etc