Hi Pete, thanks for the reply. Unfortunately they do all need to be loaded.
Basically, (sorry for not explaining it too well), if you were just going to use a few readsf~ with poly in front, i.e. forget about these tables completely, you need to wait between telling readsf~ to open and telling it to start; it can't do both straight away. That's the point of the tables: they CAN start playing the very first bit (4096 samples) straight away, and that gives enough time between telling readsf~ to open and telling it to start playing. As I say it works fine for a few pitches, and I guess it is the standard approach for these types of instrument.
So therefore you DO need a table per pitch: if you only had say six, then any note outside of those six could not be played instantly like this.
Hope that explains it better. I think the main problem is readsf~ seems to load ALL of a big file into memory, although I only want the first 4096 samples and close it after this. When I try and have 12 of these at the same time, pd dies. Does this mean pd is incapable of working as a basic soft sampler??
Er sorry for writing another essay. I'd love to hear any ideas!
Stefan
hi stephan,
could you not have less tables by not allocating each voice an array? loading soundfiles into say 6 arrays and switching between them. and as you press a key it loads the key into the oldest array/table, there's a file in the documentation about voice allocation i think....
hope this is useful
pete
___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
The following assumes that you are talking about Pd crashing when your patch loads samples via messages to [soundfiler] on startup.
I have successfully made and used a patch that loads 25 stereo WAV files into 50 tables on startup, using [soundfiler]. Each of the WAV files was 16bit stereo 44.1kHz and about 7 seconds long.
Then 96 sample players played back simultaneously a random selection of the 50 tables using [tabread~]. I could get up to 128 sample players but that didn't leave enough CPU time for the rest of the patch.
Unfortunately I seem to have deleted the whole of that patch directory by accident and I don't have a backup (which annoys me immensely).
However, the Pd version I successfully used it with was devel_0_37 configured with the threaded soundfiler patch - maybe that has something to do with success or failure.
Are you running Pd with the -rt flag? If so, perhaps the time it takes to load the samples is causing the Pd watchdog to kill Pd.
Stefan Turner wrote:
Hi Pete, thanks for the reply. Unfortunately they do all need to be loaded.
Basically, (sorry for not explaining it too well), if you were just going to use a few readsf~ with poly in front, i.e. forget about these tables completely, you need to wait between telling readsf~ to open and telling it to start; it can't do both straight away. That's the point of the tables: they CAN start playing the very first bit (4096 samples) straight away, and that gives enough time between telling readsf~ to open and telling it to start playing. As I say it works fine for a few pitches, and I guess it is the standard approach for these types of instrument.
So therefore you DO need a table per pitch: if you only had say six, then any note outside of those six could not be played instantly like this.
Hope that explains it better. I think the main problem is readsf~ seems to load ALL of a big file into memory, although I only want the first 4096 samples and close it after this. When I try and have 12 of these at the same time, pd dies. Does this mean pd is incapable of working as a basic soft sampler??
Er sorry for writing another essay. I'd love to hear any ideas!
Stefan
hi stephan,
could you not have less tables by not allocating each voice an array? loading soundfiles into say 6 arrays and switching between them. and as you press a key it loads the key into the oldest array/table, there's a file in the documentation about voice allocation i think....
hope this is useful
pete
___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Cheers for the reply. At the moment I've actually got it using readsf~, but I tried soundfiler which crashes too, even using all relevant flags.
25 7-sec stereo wavs is quite impressive, but only about half as much RAM as 12 ~30-sec stereo wavs (which I'm trying). Even though I'm only _storing_ the very first bit of each file, I can only assume that both readsf~ and soundfiler (try to) grab enough memory for the whole file. If you still had that patch it could be interesting to see how far you could push it. Sounds cool anyway if you fancy redoing it :)
I'm using PD 0.37.1 devel from PlanetCCRMA. To be honest I don't know if soundfiler is threaded in that version, but afaik readsf~ always has been, and doesn't work either. I am using -rt (kind of obligatory really) but the watchdog gives it quite a while before killing it.
I guess the only solution is making copies of the first 4096 samples of each file and loading them instead. Just thought maybe there would be an easier neater way.
Stefan Turner
--- ClaudiusMaximus gloriousclaudiusmaximus@yahoo.co.uk wrote:
The following assumes that you are talking about Pd crashing when your patch loads samples via messages to [soundfiler] on startup.
I have successfully made and used a patch that loads 25 stereo WAV files into 50 tables on startup, using [soundfiler]. Each of the WAV files was 16bit stereo 44.1kHz and about 7 seconds long.
Then 96 sample players played back simultaneously a random selection of the 50 tables using [tabread~]. I could get up to 128 sample players but that didn't leave enough CPU time for the rest of the patch.
Unfortunately I seem to have deleted the whole of that patch directory by accident and I don't have a backup (which annoys me immensely).
However, the Pd version I successfully used it with was devel_0_37 configured with the threaded soundfiler patch - maybe that has something to do with success or failure.
Are you running Pd with the -rt flag? If so, perhaps the time it takes to load the samples is causing the Pd watchdog to kill Pd.
___________________________________________________________ Win a castle for NYE with your mates and Yahoo! Messenger http://uk.messenger.yahoo.com
However, the Pd version I successfully used it with was devel_0_37 configured with the threaded soundfiler patch - maybe that has something to do with success or failure.
there was a problem with memory allocation (or to be correct memory locking) ... i _suppose_ i solved it in the recent devel_0_37 & 38
cheers ... tim
-
ClaudiusMaximus -
Stefan Turner -
Tim Blechmann