If the only non-vanilla object is [arraysize] you can substitute [expr] and make it compatible with pd-vanilla
-Jonathan --- On Sun, 4/25/10, João Pais <[email protected]> wrote: From: João Pais <[email protected]> Subject: Re: [PD] table abstractions To: "PD-List" <[email protected]>, "Matt Barber" <[email protected]> Date: Sunday, April 25, 2010, 10:36 PM I've made a [arra-yedit] abstraction. but not vanilla-only. it's not for full use, but there are some things there that might be useful. jmmmp/arra-yedit > Hello list, > > For a while there had been talk about starting a vanilla-only > table-abstraction collection in the spirit of list-abs and the iem_tab > objects. This could be useful both for manipulation of or > calculations using table data and for populating tables with desired > data (in the manner of the csound GEN routines). > > I'd love to start it, but I don't know if I have enough Pd cred yet to > be in charge of it. There are a few problems I'd like input on: > > 1) Naming -- would it be worth it to have different prefixes for > objects which manipulated data, e.g. [table-reverse], and objects > which populated tables, e.g. [tabwrite-blackman]? > > 2) Input-Output -- for the ones which manipulate data, should that > generally happen in place unless a destination table is provided -- > [table-qsort foo] sorts table values in table named foo and writes > results back to foo, while [table-qsort foo bar] would sort foo's > values and write them into bar? > > 3) In general I'm assuming that the objects which populate tables > should simply write to a table, not internally provide the table to be > written to. For instance, I'm thinking a [tabwrite-hann foo] which > writes a hann window into foo would be more useful than a [table-hann > foo] which internally instantiated a table called foo AND wrote a hann > window to it, and responded to messages like "resize" with a larger or > smaller hann window (I think accessing the table from without might be > too buggy for this to be worth it). > > 4) Interpolation -- I'm also assuming that anything which would write > a table that would usually be read by [tabread4~] or [tabosc4~] should > write the guard points for proper interpolation by default. > > > I've attached an example [tabwrite-chebyshev], which writes a weighted > sum of chebyshev polynomials of the first kind to a table, probably > for use with waveshaping, as an example of what I'm thinking of, and > of a few options members of such a collection might have. > (Incidentally, it might be a good idea to abbreviate this particular > one to "cheb" or "cheby" due to the many transliterations, or even > something like "chebsum" to name it like the sinesum or cosinesum > array methods.) > > > My thought is that many of us have already been making and using > abstractions like these, and I think it would be worth it to collect > them in a vanilla library for general use. > > Matt -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 [email protected] | skype: jmmmpjmmmp _______________________________________________ [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
