[PD] table abstractions

Mike Moser-Booth mmoserbooth at gmail.com
Fri Apr 30 05:38:43 CEST 2010

Hey Matt,

I've been on vacation the past few days, so sorry for the late reply. 
But I just wanted to say that I very much like the idea of 
table-abstractions in the vein of Csound's GEN routines. I don't think I 
could be in charge of such a project either, but I would be happy to 
contribute wherever I can.


Matt Barber wrote:
> 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
> ------------------------------------------------------------------------
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

More information about the Pd-list mailing list