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
On Mon, Jan 28, 2008 at 04:52:56PM +0100, matteo sisti sette wrote:
Suppose I create a [sample] abstraction that basically contains a
[table] to store a sound sample, and a [soundfiler] to read it from a
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):
($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
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