URGENT : sfplay~ and RAM


    Jun 14 2006 | 1:06 pm
    Hi Cycling,
    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 Terminal app). 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 ?
    Thanks,
    - and sorry, no time to google the site...
    _M

    • Jun 14 2006 | 3:48 pm
      Precision :
      same behavior with : - G5 bipro 2GHz (several), G4 Powerbook 17" - OS 10.4.5, OS 10.4.6 - Max 4.5.4, 4.5.5, 4.5.6, 4.5.7 - sfplay~ 1, 2, 4, 6, 8, 12, 16, using either [preload cueID] or [open, 1] messages - different buffer sizes - use sflist~ to preload the files, then access them with named sfplay~ - internal HD, external HD, boot from external HD (brand new OS 10.4.6) ...
      It looks that Max never frees the RAM sfplay~ uses, rather it is sent to "inactive memory", according to terminal. So, in fact, it is like sfplay loads slowly the entire soundfiles into RAM. As soon as the entire RAM is handled by Max, if I try something using another trhead (a network access, for instance), the audio starts clicking, I get random delays between the different tracks from the soundfile, etc., then crash.
      Please help - I can't buy 5 Gb of RAM to solve the problem...
    • Jun 14 2006 | 4:27 pm
      Hi,
      please can you post a patch showing this behaviour ?
      I too have experienced this same behaviour but only in certain patches (for example inside lloopp).
      I have not been able to show to Joshua an evidence of the problem
      All the best
      Alessandro Fogar
    • Jun 14 2006 | 4:41 pm
      Hi,
      just open sfplay~.help, load a long soundfile, play it and watch the RAM percentage in Terminal. Takes time if the sfplay~ is mono until the free RAM is empty (the more channels the fastest). Take several soundfiles to make a full test, since it seems that Max keeps track of preloaded files until you instanciate the object again, or quit Max.
    • Jun 14 2006 | 4:50 pm
      > > Take several soundfiles to make a full test, since it seems that > Max keeps track of preloaded files until you instanciate the object > again, or quit Max.
      Sorry, quitting is not enough - you must RESTART the machine so that Max loses track of the old preloaded file. C'mon...
    • Jun 14 2006 | 8:02 pm
      Hello Manuel,
      I made several tests here with LightRegie120x and its sound files reader. You are absolutely right, available ram decreases during playback. The mac must be restarted to recover RAM. I noticed this does not happend when you repeat a file, it's just with "new" ones. I finally - at that time- used the sflist~ option since I was never lucky with sfplay~ by itself: too many inpredictable crashes. I could simply not imagine a soundtrack abruptly stop during a theater performance... At this time, it works but in theater conditions, since soundtrack is not the most important thing, thanks to actors ;-) I use a G4 PWB 1.25 gHz / 1.25 Go ram/ Mac OSX 10.3.9 & a 1 Go USB2 key for files. The current version of LR120x use the last available version of MaxMSP. I finally made some tests with a jit.qt.movie object wich can play aif files: the phenomenon does not happen. Maybe a short term alternative for you? Best, Philippe
    • Jun 14 2006 | 8:16 pm
      Hi,
      we already talked about this here:
      Alessandro Fogar
    • Jun 15 2006 | 7:19 pm
      hi philippe / Manuel
      I made several tests too and have the same sfplay~ behaviour. I use a G4 PWB 1.25 gHz / 1.25 Go ram/ Mac OSX 10.4.6 /Max 4.5.7. Same bug whith build app.
      using jit.qt.movie is not a "MSP" alternative. using a seq. like Live, with a Max patch is a good idea to become crazy!
      So, I need a simple way to play SFiles. is it so hard to do ?
      Hope someone will solve sfplay~'S problemS. maybe at IRCAM....
      best, Francois
    • Jun 15 2006 | 8:08 pm
    • Jun 15 2006 | 10:52 pm
      while i never had this problem before, yesterday it hit on me in its full glory. a mildly complicated patch (mostly graphic stuff) for a 5.1. installation setup completely started to screw up the machine. (last days i hadnt had time to read the list, so i wasnt warned what could be going wrong).
      the things is: playing a 6 channel-.aif-file starts shifting the ram to "inactive" (as seen in terminal "top"), which is never freed. after playing a couple of those files, of course, paging starts and then things go really bad. increasing diskbuffersize was no help.
      what drove me nuts is, that it only occurs on the installation- machine (a minmac 1.42 ghz, 10.4.6, 512mb ram, max/msp/jitter runtime/ demo-mode 4.5.7). with the same patch on my pb (1.5 ghz, 1.5 g ram, 10.4.6 max/msp/ jitter) this behaviour doesnt occur. strange. even stranger: out of curiosity i made a simple pd-patch for playing the same multichannel-files. same problem on the minimac, no problem on the pb. so it seems to be some bad system voodo rather than max alone.
      my clumsy workaround: with the shell object i keep an eye on the free ram. whenever it goes below a certain threshold, audio is stopped and a buffer of approximately the size of the inactive memory is scripted and then immediately destroyed. this frees the ram again (of course, paging also happens, but it isnt that bad as before. tests still running).
      but still: what is it, that simply playing back audio-files can be such a hassle???
      puzzled hans
      p.s.: the patch to reproduce (or not) is so simple, taht i barely dont dare to attach, but anyway:
      hans w. koch im krahnenhof 11 d-50668 koeln +49-221-554902 www.hans-w-koch.net
    • Jun 16 2006 | 12:21 pm
      On Jun 15, 2006, at 10:08 PM, Joshua Kit Clayton wrote:
      > We will of course look into (don't expect an *urgent* fix by some > deadline imposed by your projects, however, as we have many > priorities and this is surely not our topmost).
      Sorry ? My project is certainly not a priority, but I would like to know if I can trust soundfiles to be played on a computer with Max or not. For the time being, it seems that I could save the installation by adding 4 Gb of RAM (soundfiles take 3.5 Gb). Fortunately, I didn't have to pull out the money from my own pocket - fortunately too, I could take enough time to track the problem (be sure that I wouldn't ring the support before at least 3 full days of hard debugging), as I'm still a (temporar) employee. As mentionned by another user, discussions around this topic started in 2004. if playing sounds with Max safely is not your topmost priority, I'm very curious to know in wich position in the list comes the present and future of doing audio with Max.
      > Also note that cues remain resident in RAM. If you just generate > more and more cues, they each will require the preload amount in > RAM (for the *lifetime* of the cue). Replacing an existing cue > number will free it and load a new one in place. However if you are > just increasing cue numbers. RAM *will* grow without bound.
      I only generate 12 cues in 2 sfplay~ object (so, 24 cues) using the [preload cue-number filename] message. Sfplay~ have an argument of 12 tracks, and the 60480 recommended value (.help) for the buffer size argument. Soundfiles have a length around 2mn each, each output is connected to a dac-number. Then I play those 24 cues one after the other, using an int corresponding to the cue-number. The total length of the loop is about 48 mn, wich is repeated from 11 a.m to 22 p.m. That's all what I'm doing there.
      > As for cue list looping leading to VRAM issues (including in a > multi-channel setting), I've attached the following patch which > does n cause RAM to grow without bound on my machine 10.4.7. Does > this patch grow without bound for you, Manuel?
      As far as I can see, no. Have a look on the patch issued from mine (maybe generate a 12 tracks soundfile - I've put a small recorder inside - and replace the filenames with yours). This one does.
      Thank you,
      _Manuel
    • Jun 16 2006 | 3:20 pm
      If I recall correctly it was I who instigated a lot the discussion regarding the problems with sfplay~. Mainly it not playing without a second trigger. I found the main cause to be drive speed. It was running on a powerbook at the time, moving all the audio onto a fast firewire drive cured it for me, but I did end up using Live for all critical audio just for safetys sake.
      My apologies if this has already been suggested as I haven't been following the thread.
      Peas
      Dom
    • Jun 16 2006 | 4:37 pm
      > Hope someone will solve sfplay~'S problemS. > maybe at IRCAM....
      a good joke ?-)
    • Jun 16 2006 | 6:34 pm
      On Jun 16, 2006, at 8:20 AM, Dominic Melville wrote:
      > If I recall correctly it was I who instigated a lot the discussion > regarding the problems with sfplay~. Mainly it not playing without > a second trigger. I found the main cause to be drive speed. It was > running on a powerbook at the time, moving all the audio onto a > fast firewire drive cured it for me, but I did end up using Live > for all critical audio just for safetys sake.
      This is a different issue. That problem you are referring to is that you need to disable HD sleep, or make sure the preload buffer is large enough to wait for HD wake-up.
      -Joshua
    • Jun 16 2006 | 7:54 pm
      On Jun 16, 2006, at 5:21 AM, Manuel Poletti wrote: > As mentionned by another user, discussions around this topic > started in 2004. > if playing sounds with Max safely is not your topmost priority, I'm > very curious to know in wich position in the list comes the present > and future of doing audio with Max.
      In case it's not obvious, we are committed to providing as robust and reliable audio features as possible. Unfortunately, as far as we can verify, Max is working properly in this regard. So it is for marginal cases (which we are unable to verify) which this is an issue. I appreciate your frustration, but while soundfile playback from disk might seem to be a simple and fundamental operation to you, it is actually quite complex, especially with sample accurate cue triggering and looping, variable speed playback, management of arbitrary channel/bitdepth/ sample rate sound files in the same circular buffer fed from disk, not to mention taking into account everything that happens under the hood in the OS with respect to memory management, disk access, and file I/O (which, as far as I can tell, sounds like where these sorts of reports are having a problem).
      Thank you for the clear example. These are always recommended for any reports.
      After initial preload of 11 cues of 12 channel pink noise files (10-15 seconds each): 17846 MaxMSP 19.2% 2:12.15 22 651 694 32.6M 35.5M 51.0M 830M
      After playback for several repetitions we have no signs of any increase in RAM usage: 17846 MaxMSP 20.0% 16:43.68 22 652 694 32.7M 35.6M 50.9M 830M
      I also don't see the inactive RAM steadily growing as Hans Koch reported on the MacMini using either MaxMSP or PD. It just fluctuates within a 16MB range.
      I'll leave in the background playing longer, but this leads me to think that it is an OS issue as had been discussed in the previous thread, and as suggested by Hans Koch's post on the subject. I'll try to do a bit more research on how this might be the case, but, until we can establish the problem, we can't fix it. Even if we do establish the problem, it sounds like it might be in the OS and out of our control. Hans' fix for the inactive memory is also a curious one, seemingly related to the memory manager's inner workings rather than anything in MaxMSP's code.
      -Joshua
    • Jun 17 2006 | 11:06 am
      > In case it's not obvious, we are committed to providing as robust > and reliable audio features as possible.
      It is - I've experimented too many local cases where this kind of sentence had to be understood as a legend, to not appreciate the responsiveness here. That's why I now use external pattented software (since 1997...). But it's hard for me to hear that audio playback is not a prior feature to be fixed in a software that is intended to produce audio. Numerous twisted real time/interactive/stochastic... anyway bloody projects could be saved in the last minute using the old good "tape". That's what I hoped I could do using sfplay~.
      > Unfortunately, as far as we can verify, Max is working properly in > this regard. So it is for marginal cases (which we are unable to > verify) which this is an issue. I appreciate your frustration, but > while soundfile playback from disk might seem to be a simple and > fundamental operation to you, it is actually quite complex, > especially with sample accurate cue triggering and looping, > variable speed playback, management of arbitrary channel/bitdepth/ > sample rate sound files in the same circular buffer fed from disk, > not to mention taking into account everything that happens under > the hood in the OS with respect to memory management, disk access, > and file I/O (which, as far as I can tell, sounds like where these > sorts of reports are having a problem).
      I fully understand that what seems obvious as a software feature since Sound Accelerator & co appeared is hard to maintain over so many versions of systems - especially when it has hundreds of neighbours sitting in the same directory. But, since 1997, it is no more a marginal idea for the happy Maxers like me to intend to simply play looped multichannel files from a patcher during a "serious" production. So, excuse my surprise : if Digidesign couldn't handle soundfile playback safely, they would be dead today. It makes me remember "Jamais"-Max - wich disappeard ages ago - there never were reliable soundfile playback...
      > Thank you for the clear example. These are always recommended for > any reports. > > After initial preload of 11 cues of 12 channel pink noise files > (10-15 seconds each): > 17846 MaxMSP 19.2% 2:12.15 22 651 694 32.6M 35.5M > 51.0M 830M > > After playback for several repetitions we have no signs of any > increase in RAM usage: > 17846 MaxMSP 20.0% 16:43.68 22 652 694 32.7M 35.6M > 50.9M 830M
      Yes - Max seems to remain stable. On my powerbook (so, another machine), when I load the test patch (with soundfiles preloaded), top says :
      Processes: 52 total, 2 running, 50 sleeping... 213 threads 12:36:05 Load Avg: 1.24, 0.65, 0.33 CPU usage: 23.7% user, 17.8% sys, 58.5% idle SharedLibs: num = 177, resident = 41.9M code, 4.78M data, 8.99M LinkEdit MemRegions: num = 5172, resident = 133M + 10.3M private, 121M shared PhysMem: 92.7M wired, 135M active, 238M inactive, 466M used, 557M free VM: 5.02G + 109M 27643(0) pageins, 0(0) pageouts
      283 MaxMSP 4.5 14.4% 1:12.18 26 804 605 38.3M 28.4M 51.8M 682M
      After 10 minutes of playback, top displays :
      Processes: 52 total, 3 running, 49 sleeping... 212 threads 12:45:40 Load Avg: 0.96, 1.04, 0.73 CPU usage: 33.3% user, 22.0% sys, 44.7% idle SharedLibs: num = 177, resident = 38.0M code, 4.38M data, 6.15M LinkEdit MemRegions: num = 5143, resident = 133M + 10.3M private, 116M shared PhysMem: 92.9M wired, 182M active, 735M inactive, 1011M used, 12.8M free VM: 4.93G + 109M 27656(0) pageins, 58(6) pageouts
      283 MaxMSP 4.5 22.4% 3:42.96 26 804 605 39.2M 26.7M 52.7M 682M
      So, Max is OK, but the free RAM is put into inactive, and not "given back" unless you restart the machine. Then the proportions of RAM remain more or less like that. If I run the files during hours, Max will crash soon or later. Now, we've added 4 Gb of RAM - + the original 1.5 Gb, wich is enough to fit the 3.5 Gb of soundfiles in RAM - free RAM (1.5 Gb) is stabilized once the whole files are read entireley, and Max doesn't crash anymore.
    • Jun 17 2006 | 12:54 pm
      hi,
      just joining in to confirm that there is more people out there having the same problem - sfplay eating all the ram....
      On 15.06.2006, at 22:08, Joshua Kit Clayton wrote:
      > Replacing an existing cue number will free it and load a new one in > place.
      exactly this is not happening on my system (I have to reboot the computer to get the ram back):
      titanium 1 GHz, 10.3.8, max/msp 4.5.7
      .....would be really great if there would be a fix sometimes......
      best noid
      arnold haberl: noid@klingt.org dornerplatz 13/32, a-1170 wien +43-699-11 88 59 39 http://noid.klingt.org/
    • Jun 17 2006 | 6:40 pm
      I stopped using sfplay~ in public performance several years ago due to unreliable playback (though it remains an excellent and valuable external for use in the studio). Instead I adopted the obvious solution of loading sounds into buffers for playback with groove~, but in that case of course you're limited by the amount of RAM on your machine.
      Joshua's point is well-taken that unless the problem can be localized and made repeatable it is not easily solved. OTOH, on the same machine where I have had sfplay~ choke on a single stereo file (TiBook 1GHz, 512 MB RAM), I have never experienced a similar event from iTunes, or for that matter from Logic or Digital Performer. Or SoundHack. That suggests that, in theory, the problem could be solved. I'm not surprised that Pd gives similar performance, but it might still be worth checking if the SuperCollider or Csound disk file players prove more reliable.
      In any case, even though this is reportedly a marginal problem (though of course it's not marginal if it happens on *your* machine, especially in front of an audience), it would be nice if a universally reliable solution were found, because soundfile playback is a core functionality. Maybe even worth redesigning sfplay~ from scratch.
      Best, Eric
    • Jun 17 2006 | 6:47 pm
      Btw, I think we will be able to have this problem solved in the next version of MaxMSP. It appears to be strange behavior in the File Manager's caching implementation which is an issue only on some machines (none of which I own). There are ways to avoid the File Manager's cache implementation which we will use in the next version. Thanks for your persistence in bringing this problem to our attention.
      -Joshua
    • Jun 17 2006 | 7:16 pm
      On Jun 17, 2006, at 11:40 AM, Eric Lyon wrote:
      > Joshua's point is well-taken that unless the problem can be > localized and made repeatable it is not easily solved. OTOH, on the > same machine where I have had sfplay~ choke on a single stereo file > (TiBook 1GHz, 512 MB RAM), I have never experienced a similar event > from iTunes, or for that matter from Logic or Digital Performer.
      Hi Eric,
      The above sounds like the well known HD sleep problem often discussed on the list (and solutions posted for). And yes, Logic, and other applications which require a similar sort of real time delivery from the HD in time to synchronize with the RAM preloaded to play the region will stop playback in such an instance that the HD cannot wake up and deliver audio in time. This happens to me all the time in Logic when the HD goes to sleep...all playback stops and I get a dialog about not being able to synchronize audio. You might not notice this if you just launch the program and hit play, since in such a setting, the disk is almost always active, but if you pause with enough time for the disk to sleep, I believe you should be able to reproduce(unless your disk buffers in Logic are large enough to compensate for this behavior...same is true for sfplay~). Note that this is not the case with Sound Hack or iTunes, since in those applications it is permissible to simply start playback once the disk becomes active.
      One solution to this problem is to not let the HD go to sleep. It has been discussed that while MaxMSP is running, it should not let the HD go to sleep, which we could do. However, I'm not sure that this is a universally acceptable solution since people use MaxMSP for a variety of different needs and so this should be configurable (but if configurable, you can already do so in the energy saver control panel, or use a large enough diskbuffer size to accommodate the slowest of HD wakeups).
      -Joshua
    • Jun 17 2006 | 10:01 pm
      my tests led me to the same conclusion, since i experienced the very same behaviour with pure-data and vlc-player on a machine which choked on sfplay. the same patches run fine on another computer which has no problems with sfplay either. (see my post on this thread on june 16th)
      weird it is. hans
      hans w. koch im krahnenhof 11 d-50668 koeln +49-221-554902 www.hans-w-koch.net
    • Jun 18 2006 | 7:35 am
      Hi,
      consider that on my machine the sfplay~ inside a lloopp patch eats ram.
      Instead, an sfplay~ inside the sfplay~.help or the patch submitted some time ago by Noid does not eat Ram.
      If you want I can provide patch examples.
      All the best
      Alessandro Fogar
    • Jul 24 2006 | 11:32 am
      Did this fix make it into the current 4.6 public Beta? Also, do you have a list of the machines know to be problematic?
      Many thanks, Neal
      Btw, I think we will be able to have this problem solved in the next version of MaxMSP. It appears to be strange behavior in the File Manager's caching implementation which is an issue only on some machines (none of which I own). There are ways to avoid the File Manager's cache implementation which we will use in the next version. Thanks for your persistence in bringing this problem to our attention.
      -Joshua
    • Jul 24 2006 | 5:50 pm
      On Jul 24, 2006, at 4:32 AM, neal wrote:
      > Did this fix make it into the current 4.6 public Beta?
      Yes.
      > Also, do you have a list of the machines know to be problematic?
      It is not specifically a HW problem, but rather a software behavior (Finder's File caching strategy) which we have no data that would explain why it provides different behavior at different times. Seems like it might be a bug or idiosyncrasy in Apple's algorithm for determining how much and how long to cache file information. As previously mentioned I've never been able to reproduce these problems (meaning whatever voodoo that needs to be in place on my machine for Apple's file caching to work the way I'd expect it to).
      -Joshua
    • Jul 25 2006 | 11:41 am
      Excellent, will start to move over to 4.6. I know this has been a long-running thread, and a frustrating (non-c74) bug for you guys to fix... Thanks for the new version.
      Neal
      > > > Did this fix make it into the current 4.6 public Beta? > > Yes. >
    • Jul 25 2006 | 2:16 pm
      On 6/17/06, Manuel Poletti wrote: > On my powerbook (so, another machine), when I load the test patch (with > soundfiles preloaded), top says : > > Processes: 52 total, 2 running, 50 sleeping... 213 threads > 12:36:05 > Load Avg: 1.24, 0.65, 0.33 CPU usage: 23.7% user, 17.8% sys, 58.5% > idle > SharedLibs: num = 177, resident = 41.9M code, 4.78M data, 8.99M LinkEdit > MemRegions: num = 5172, resident = 133M + 10.3M private, 121M shared > PhysMem: 92.7M wired, 135M active, 238M inactive, 466M used, 557M free > VM: 5.02G + 109M 27643(0) pageins, 0(0) pageouts > > 283 MaxMSP 4.5 14.4% 1:12.18 26 804 605 38.3M 28.4M 51.8M 682M > > > > After 10 minutes of playback, top displays : > > Processes: 52 total, 3 running, 49 sleeping... 212 threads > 12:45:40 > Load Avg: 0.96, 1.04, 0.73 CPU usage: 33.3% user, 22.0% sys, 44.7% > idle > SharedLibs: num = 177, resident = 38.0M code, 4.38M data, 6.15M LinkEdit > MemRegions: num = 5143, resident = 133M + 10.3M private, 116M shared > PhysMem: 92.9M wired, 182M active, 735M inactive, 1011M used, 12.8M free > VM: 4.93G + 109M 27656(0) pageins, 58(6) pageouts > > 283 MaxMSP 4.5 22.4% 3:42.96 26 804 605 39.2M 26.7M 52.7M 682M > > > So, Max is OK, but the free RAM is put into inactive, and not "given back" > unless you restart the machine.
      I don't see why this is a problem. I don't use MacOS X much these days, but on most modern *nix machines, this is normal behaviour. This is just buffer cache and will be given up to an application the moment it needs it.
      Basically, what's happening is that the OS is being smart and storing data into RAM since there's no real value in wiping it. If you ever need that data again, it will already be in RAM, if you don't and need the RAM, it is given up to the OS/Application. Unless the OS does something dumb and starts swapping heavily (which doesn't seem to be the case here), this is not a problem at all.
      Cheers,
      Chris
    • Jul 25 2006 | 2:33 pm
      Hi,
      Christopher Murtagh said:
      > Unless the OS does > something dumb and starts swapping heavily (which doesn't seem to be > the case here), this is not a problem at all.
      Yes, but this is the case, the OS DOES start swapping and audio dropouts occour.
      Otherways why do you think that we did pose the problem ?
      This is not something happening in OS theory this happens on our machines.
      One year ago I had to rewrite one piece of mine cause this problem (otherways I had to buy 2 Gb of Ram but I am not Ircam, you know :-) ) ...
      Let's hope it is solved now...
      Peace , all the best
      Alessandro Fogar
    • Jul 25 2006 | 3:00 pm
      On 7/25/06, Alessandro Fogar wrote: > Hi, > > Christopher Murtagh said: > > > Unless the OS does > > something dumb and starts swapping heavily (which doesn't seem to be > > the case here), this is not a problem at all. > > Yes, but this is the case, the OS DOES start swapping and audio dropouts occour. > > Otherways why do you think that we did pose the problem ?
      Oh, sorry. I didn't see this in the thread, but re-reading it now I can see it. If this is the OS doing something dumb, this could be pretty hard for the cycling74 guys to fix. Ahh, the joys of the spinning lollipop - this is why I use Linux most of the time. :-)
      If however, the sfplay~ object is *always* loading entire samples into RAM regardless of their size (instead of buffering and loading as needed - a much more complex but obviously necessary task for large samples), it should be considered a limitation of the object. Using it to play 1GB audio files would be the equivalent of transporting elephants with a VW Bug. Perhaps it was just designed to handle short audio samples by the original author and therefore it's a useage and/or documentation problem? In either case a more appropriate object would be needed, maybe one that's always loaded (for small samples) and one that's buffered (for large files) would be the best approach?
      Cheers,
      Chris
    • Jul 25 2006 | 3:08 pm
      On 25 Jul 2006, at 17:00, Christopher Murtagh wrote:
      > If however, the sfplay~ object is *always* loading entire samples > into RAM regardless of their size (instead of buffering and loading as > needed - a much more complex but obviously necessary task for large > samples), it should be considered a limitation of the object.
      sfplay~ doesn't do this. It preloads and buffers some audio, and operates by streaming.
      -- N.
      nick rothwell -- composition, systems, performance -- http:// www.cassiel.com
    • Jul 25 2006 | 6:03 pm
      On 25-Jul-2006, at 17:00, Christopher Murtagh wrote:
      > would be the equivalent of transporting > elephants with a VW Bug
      Oh, no! Not a revival of the "how many elephants can you get into a VW Beetle" jokes. I hoped I heard the last one of those in 1967.
      -- P.
      -------------- http://www.bek.no/~pcastine/Litter/ ------------- Peter Castine +--> Litter Power & Litter Bundle for Jitter Universal Binaries on the way iCE: Sequencing, Recording & Interface Building for |home | chez nous| Max/MSP Extremely cool |bei uns | i nostri| http://www.dspaudio.com/ http://www.castine.de
    • Jul 26 2006 | 10:40 am
      Wasn't that the Ultimate Question?
      ;-)
      Trond > Oh, no! Not a revival of the "how many elephants can you get into a VW > Beetle" jokes. I hoped I heard the last one of those in 1967.