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

[Charles Henry]

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