2008/1/29, Charles Henry <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]> 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 > > > [EMAIL PROTECTED] > > > http://www.matteosistisette.com > > > > > > _______________________________________________ > > > [email protected] mailing list > > > UNSUBSCRIBE and account-management -> > > > http://lists.puredata.info/listinfo/pd-list > > > > > > _______________________________________________ > > [email protected] mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > -- Matteo Sisti Sette [EMAIL PROTECTED] http://www.matteosistisette.com _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
