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...
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@gmail.com http://www.matteosistisette.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Just a guess... maybe allocating all that memory is forcing the OS to page other apps out.
I can't discard that, but... Correct me if I am wrong: if that was the case, removing the [tabplay~]s shouldn't make a difference, should it?
I removed the tabplay~s but the number of tables and size of the sound samples are the same, and now it loads all samples much much faster.
To "rephrase" the whole problem in a simpler way, consider this:
A) N occurrences of: [table table-K] [soundfiler]
[tabplay~ table-K]
(with K=1,2,...,N)
Versus this:
B) N occurrences of just [table table-K] and [soundfiler] and only one unique [tabplay~].
When I "load" samples, each soundfiler receives a [read -resize something.wav table-K( message.
In case (A) loading all samples is much slower.
My guess was the following: "Every time a soundfiler loads a file into an array, and therefore resizes it, the DSP graph (or SOMETHING) is recomputed. In PD's data structures, for some reason each table has some sort of link to any [tabplay~] or [tabread~] object "attached" to it (in this case one tabplay per table). So when recomputing the whole data structure (once per table resize) there's some kind of operation that is being done N times in case A and zero or one times in case B."
.... Or maybe the first part is correct and the second part is much simpler?: "Evert time a soundfiler loads a file into an array, and therefore resizes it, the DSP graph is recomputed, and the time needed to do this is proportional to the number of existing "~" objects. Therefore removing a big number of useless [tabplay~]s is reducing the size of the graph and time needed to calculate it."
Is any of my two guesses even near to correct?
Thanks a lot m.
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@gmail.com http://www.matteosistisette.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Another diagnostic idea: try comparing the behavior during loading with audio switched on and off. my guess is: if this is a memory issue, it won't make a difference if it's the computations involved with big #'s of tabplay~, then it will be faster with audio off
Chuck
On Jan 29, 2008 1:21 PM, Matteo Sisti Sette matteosistisette@gmail.com wrote:
Just a guess... maybe allocating all that memory is forcing the OS to page other apps out.
I can't discard that, but... Correct me if I am wrong: if that was the case, removing the [tabplay~]s shouldn't make a difference, should it?
I removed the tabplay~s but the number of tables and size of the sound samples are the same, and now it loads all samples much much faster.
To "rephrase" the whole problem in a simpler way, consider this:
A) N occurrences of: [table table-K] [soundfiler]
[tabplay~ table-K]
(with K=1,2,...,N)
Versus this:
B) N occurrences of just [table table-K] and [soundfiler] and only one unique [tabplay~].
When I "load" samples, each soundfiler receives a [read -resize something.wav table-K( message.
In case (A) loading all samples is much slower.
My guess was the following: "Every time a soundfiler loads a file into an array, and therefore resizes it, the DSP graph (or SOMETHING) is recomputed. In PD's data structures, for some reason each table has some sort of link to any [tabplay~] or [tabread~] object "attached" to it (in this case one tabplay per table). So when recomputing the whole data structure (once per table resize) there's some kind of operation that is being done N times in case A and zero or one times in case B."
.... Or maybe the first part is correct and the second part is much simpler?: "Evert time a soundfiler loads a file into an array, and therefore resizes it, the DSP graph is recomputed, and the time needed to do this is proportional to the number of existing "~" objects. Therefore removing a big number of useless [tabplay~]s is reducing the size of the graph and time needed to calculate it."
Is any of my two guesses even near to correct?
Thanks a lot m.
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@gmail.com http://www.matteosistisette.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2008/1/29, Charles Henry czhenry@gmail.com:
Another diagnostic idea: try comparing the behavior during loading with audio switched on and off.
Whops, I hadn't thought about that :$ Thank you :)
my guess is: if this is a memory issue, it won't make a difference if it's the computations involved with big #'s of tabplay~, then it will be faster with audio off
Yessssssssssss! I reverted (temporarily) to the version with many tabplays, and indeed: with audio off it is muuuuuch faster, about as fast as the version without tabplays.
So it is definitely not a memory issue.
Now, out of mere insane curiosity, I made the following test: In the "sample" abstraction, I replaced this:
[table $1] ... [tabplay~ $1]
with this:
[table $1] ... [tabplay~]
I tried the load with audio on, and surprise! I get the same speedup as removing tabplay~s or switching off audio!
So the fact that the tabplays are "linked" to tables (or viceversa) is definitely relevant.
Chuck
On Jan 29, 2008 1:21 PM, Matteo Sisti Sette matteosistisette@gmail.com wrote:
Just a guess... maybe allocating all that memory is forcing the OS to page other apps out.
I can't discard that, but... Correct me if I am wrong: if that was the case, removing the [tabplay~]s shouldn't make a difference, should it?
I removed the tabplay~s but the number of tables and size of the sound samples are the same, and now it loads all samples much much faster.
To "rephrase" the whole problem in a simpler way, consider this:
A) N occurrences of: [table table-K] [soundfiler]
[tabplay~ table-K]
(with K=1,2,...,N)
Versus this:
B) N occurrences of just [table table-K] and [soundfiler] and only one unique [tabplay~].
When I "load" samples, each soundfiler receives a [read -resize something.wav table-K( message.
In case (A) loading all samples is much slower.
My guess was the following: "Every time a soundfiler loads a file into an array, and therefore resizes it, the DSP graph (or SOMETHING) is recomputed. In PD's data structures, for some reason each table has some sort of link to any [tabplay~] or [tabread~] object "attached" to it (in this case one tabplay per table). So when recomputing the whole data structure (once per table resize) there's some kind of operation that is being done N times in case A and zero or one times in case B."
.... Or maybe the first part is correct and the second part is much simpler?: "Evert time a soundfiler loads a file into an array, and therefore resizes it, the DSP graph is recomputed, and the time needed to do this is proportional to the number of existing "~" objects. Therefore removing a big number of useless [tabplay~]s is reducing the size of the graph and time needed to calculate it."
Is any of my two guesses even near to correct?
Thanks a lot m.
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@gmail.com http://www.matteosistisette.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Charles Henry -
Matteo Sisti Sette -
matteo sisti sette
-
Miller Puckette