Hans Roels wrote: > Apart from [soundfiler] I use this trick to get the size of any array > (audio or data) in pd vanilla: > (array1 = the name of an example array) > > bang > | > [expr size("array1")] > | > print > > or replace the expr with [expr size("$s2")] and connect a message > [symbol array1( to the second inlet of this expr object > > hans r
hi, that's cool. did not know that expr can do that! are there more features of expr that are hidden or unknown?? marius. > > At 09:38 11/06/2008, you wrote: >> On Wed, Jun 11, 2008 at 10:03:28AM +0200, IOhannes m zmoelnig wrote: >>> raul diaz wrote: >>>> I have a dumb question. What's the best way to get the size of a table? >>>> Sometimes I load a lot of samples on tables with soundfiler and I would >>>> like to take the size of each sample as a variable in order to use it >>>> with phasor + tabread4~. >>>> Is there any object which gets the size of a table? >>> well i have a dumb answer: why not use the "length" output of [soundfiler]? >>> >>> i think that in this case the philosophy of Pd his, that there are 2 >>> ways to change the length of a table: do it interactively (e.g. create a >>> [table bla 1024] or do it programmatically (e.g. via [; bla resize 216() >>> in the first case the author of the software is responsible for using >>> (e.g. "hardcoding") the right table-size throughout there patch, in the >>> latter case you could just listen to these programmatical changes). >>> tables suddenly changing there size are beyond Pd :-) >> There is one situation I have encountered where it would be useful to >> have a built in [arraysize]. In some of the s-abstractions such as >> [s-samplepiece~] you have to pass in the table name that you'd like the >> abstraction to use. This means that at some point the user loads some >> audio data into the named table (for example using [s-loader~]) and they >> then know the sample table size. When they create the [s-samplepiece~] >> playback abstraction they must manually enter the array size as one of >> the arguments to the abstraction, along with the table name. >> Inefficient. >> >> Best, >> >> Chris. >> >> ------------------- >> http://mccormick.cx >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list