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 <[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 > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
