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:
- 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]?
- 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?
- 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).
- 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