Multisample memory management / streaming samples from disk
mikejarod
NLPosts: 11
According to the manual: The Deluge streams audio samples directly off the SD card, meaning there
is no practical limit on the amount of sample content that may be used per
song, and the user does not have to wait for all sample data to be read
when loading a song.
I made a multisample patch using a lot of long samples (4 octaves, all notes, 8 sec per note, total around 100mb). When I use longer release times and play a lot of notes like an 8th arp, with some notes the deluge becomes unresponsive. So it appears I am reaching some performance cap.
Is it correct there is no way to set the max amount of polyphonic voices per patch? I only see mono and poly but not a number for poly. That would be helpful in this case.
Can someone confirm the Deluge should be streaming the samples from disk thus being as efficient as possible, or are all the samples stored in RAM?
Any tips for improving performance in this case?
Comments
Arps are best used with polyphony set to mono, otherwise you end up generating dozens of voices. Or at least be very considerate with release time. Also the samples should be 44100 16 bit, otherwise deluge needs to use interpolation thus impacting performance. Also also, there's currently some problems with samples performance on the 4.0 firmware which are currently looked into and fixed in the 4.1 update soon. Almost forgot, there's no way to set number of voices per patch, but it would be a great addition for sure.
🅽🅾🆅🅸🅲🅴 🅳🅴🅻🆄🅶🅸🅾🅽🅸🆂🆃?
Yeah not sure of the exact details or why they say that but there’s definitely a limit. Maybe someone less ignorant than me can explain it better but at some point you start hitting what seems to be an internal RAM or CPU processing limit. And it’s not the card. I bough a very fast one thinking it would improve the number of clips I could play at a time and it didn’t help at all.
I can basically add tracks until I start hearing drops. At that point I stop adding more and set the clip that’s dropping to ‘High’ priority. It fixes the drop issue at that point but if I continue to add more clips it starts happening again and the priority setting doesn’t help anymore.
Perhaps someone can better explain?
Thanks. The problem I experienced, unresponsiveness, seems to be related to OSC mode set to LOOP. I used oneshot samples set to LOOP which was unintentional. In this mode it seems that notes continue to go on even if the note is already off / release phase has already ended. @volsteh is that whay you meant with "some problems with sample performance"?
If I set OSC mode to ONCE or CUT, then I get a really nice amount of voices without any problems. Also when using longer release times.
Not sure about that. The problems where reported by users opening songs from v3 in v4. Songs that played fine in v3 had audio dropouts and clicks in v4. I also noticed in new songs that I reach the cpu limit faster than in v3. Hopefully the update gonna fix this.
🅽🅾🆅🅸🅲🅴 🅳🅴🅻🆄🅶🅸🅾🅽🅸🆂🆃?