I'm experimenting strange RAM behaviour while using sfplay~ in
multichannel mode :
whatever the number of channels is - 4, 8, 6, 12 or 16 - , when I
preload several soundfiles into sfplay cues, and start playing each
cue sequentially, the RAM used by MSP is continuously increasing,
once the preloaded part of the sound has been read (cf "top" in
As I loop the sequence of cues, the free RAM gets soon totally
fullfilled, then, soon or later, Max simply quits - no crash log or so.
It looks like sfplay~ continuously "preloads" the part of sound it
has to play, without ever clearing the already-read part from the RAM.
Of course, I've tried, changing buffer size, using sflist~, splitting
soundfiles in smaller formats, installing a new system, on several
machines, downgrading Max to earlier versions, etc : same behaviour.
Thank you for a quick help from Cycling developers, we're several
here to experiment LOTS of problems with sfplay~ in general, and THIS
OBJECT IS TOO IMPORTANT for live performances (some are thinking
using readsf~ from PD, via flext - cool).
I have now a new sound installation wich cannot run safely, due to that.
We must know if we can finally trust or not a simple multichannel
soundfile player in Max - or should we use f%$#@#@ sequencer ?
- and sorry, no time to google the site...