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

[Matteo Sisti Sette]

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