sflist vs sfplay


    Nov 08 2006 | 7:23 pm
    hi andrew,
    how many samples do you play at a time? hard drive read speed might be the source of the bottleneck, if your HD isn't 7200 rpm or even then you can't read 100 samples at a time. I haven't looked at the patch but could that be it?
    - george
    On 11/8/06, Andrew Burke wrote: > > > I am having problems with my scheduler. I have a patch that is collaging > several 1000 short samples. For several groups of samples I use select and > random objects to trigger them to play. Inside these groups I have one > sfplay object linked up with 10 messages of (open sound1.wav, 1). I > thought that this would be less demanding than having an sflist object for > each of my samples, but now that it is not working well I am wondering if > the massive amounts of low priority events (opening the sound files) is > causing the problem. I have fiddled with the scheduler in overdrive, > optimize, and performance options to the best of my knowledge without much > success. I am running about 20% of my cpu and have 1 gig of ram. Before I > completely reright my patch does anyone know if preloading all of the files > will help? Below is an example of one part of my patch. > > Thanks, > Andrew > >

    • Nov 08 2006 | 9:54 pm
    • Nov 09 2006 | 9:22 am
      On 8 nov. 06, at 20:23, Andrew Burke wrote:
      > I am having problems with my scheduler. I have a patch that is > collaging several 1000 short samples. For several groups of samples I > use select and random objects to trigger them to play. Inside these > groups I have one sfplay object linked up with 10 messages of (open > sound1.wav, 1). I thought that this would be less demanding than > having an sflist object for each of my samples,
      if you don't preload your files, your patch will be in troubles sooner or later. As I wrote recently, write a [coll] to preload your files (don't save its content in the patch but in an external file). It has many advantages, one of them being the fact that the names of your audio files are abstracted from your patch. So you can easily change them without editing the patch, which may be handy for standalones.
      _____________________________ Patrick Delges
      Centre de Recherches et de Formation Musicales de Wallonie asbl http://users.skynet.be/crfmw/max
    • Nov 16 2006 | 7:06 am
      Andrew Burke wrote: > I am having problems with my scheduler. I have a patch that is > collaging several 1000 short samples. For several groups of samples > I use select and random objects to trigger them to play. Inside > these groups I have one sfplay object linked up with 10 messages of > (open sound1.wav, 1). I thought that this would be less demanding > than having an sflist object for each of my samples, but now that it > is not working well I am wondering if the massive amounts of low > priority events (opening the sound files) is causing the problem. I > have fiddled with the scheduler in overdrive, optimize, and > performance options to the best of my knowledge without much success. > I am running about 20% of my cpu and have 1 gig of ram. Before I > completely reright my patch does anyone know if preloading all of the > files will help? Below is an example of one part of my patch.
      Nobody commented about the actual patch you posted yet. First, I'd recommend to encapsulate similar constructions into abstractions. Then you can just simply duplicate them and define the differences with parameters. If you want to connect one element (the start for all metros for example) to the same element within that (encapsulated) part, its better and easier to read if you use a send object and a receive for each subpatcher... In your example you would get rid of most of the patch chords which hide the view of your patcher...
      just a starting point (including preloading the sound files):
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com