Andrew Burke

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

> 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.

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?

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
>
>

sflist-vs-sfplay

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 

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.

Centre de Recherches et de Formation Musicales de Wallonie asbl

> 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


> 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 

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 

In your example you would get rid of most of the patch chords which hide 

just a starting point (including preloading the sound files):

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...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


sflist vs sfplay