[PD] one more boring computation-time cuestion of mine...

[Miller Puckette]

Just a guess... maybe allocating all that memory is forcing the OS to
page other apps out.  (I'm not sure how much memory is getting used but
if it's more than 1/4 of the system total it's possible that is slowing
stuff down.)

cheers
Miller

On Mon, Jan 28, 2008 at 04:52:56PM +0100, matteo sisti sette wrote:
> Hi,
> 
> Suppose I create a [sample] abstraction that basically contains a
> [table] to store a sound sample, and a [soundfiler] to read it from a
> file.
> 
> One of the reasons for creating such a "trivial" abstraction is that
> it has a GOP GUI with
> -a symbolbox where you can write and see the filename
> -a test button that plays the sample.
> 
> Now suppose the test part is implemented like this (simplified):
> 
> [r $1-test]
> |
> [tabplay~ $1]
> |
> [throw~ sampletestout]
> 
> 
> ($1 is the name of the sample, i.e. the name of the table, and the GUI
> is supposed to have a bng sending to $1-test)
> 
> Obviously, to avoid unnecessary cpu-usage, that would become enormous
> if I have many sample instances, I will include the necessary patching
> in the abstraction in order to [switch~] it on only when playing, and
> off when not. Usually you'll be testing at most one sample at the same
> time.
> 
> Now the question is: in case there are N [sample]s in my patch,
> Is it possible that the time needed to load ONE sample (sending a
> [read...( message to the [soundfiler]) increases with N???
> If so, why?
> 
> The fact is that I have been using such an abstraction very much, and
> have a great number of [sample]s in my patch, and started to notice
> that loading all the samples was terribly slow.
> Then, without thinking it had any relation to this, I realised I could
> easily remove all the "~" part from the sample abstraction, by
> implementing a unique [sampletester] and having [sample]s sending him
> messages to test one sample.
> I did this, and removed the [tabplay~] thing from the [sample]
> abstraction, and now the loading of samples seems to be enormously
> faster...
> 
> 
> 
> -- 
> Matteo Sisti Sette
> matteosistisette at gmail.com
> http://www.matteosistisette.com
> 
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list