[PD] table abstractions

Jonathan Wilkes jancsika at yahoo.com
Mon Apr 26 00:57:59 CEST 2010

If the only non-vanilla object is [arraysize] you can substitute [expr] and make it 
compatible with pd-vanilla


--- On Sun, 4/25/10, João Pais <jmmmpais at googlemail.com> wrote:

From: João Pais <jmmmpais at googlemail.com>
Subject: Re: [PD] table abstractions
To: "PD-List" <pd-list at iem.at>, "Matt Barber" <brbrofsvl at gmail.com>
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.


> 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
jmmmpais at googlemail.com | skype: jmmmpjmmmp

Pd-list at iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100425/76731525/attachment.htm>

More information about the Pd-list mailing list