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