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

matteo sisti sette matteosistisette at gmail.com
Wed Jan 30 11:09:48 CET 2008


2008/1/29, Charles Henry <czhenry at 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 at 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 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
> >
> >
> > _______________________________________________
> > PD-list at iem.at mailing list
> > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >
>


-- 
Matteo Sisti Sette
matteosistisette at gmail.com
http://www.matteosistisette.com




More information about the Pd-list mailing list