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
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:
- 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
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 jmmmpais@googlemail.com wrote:
From: João Pais jmmmpais@googlemail.com Subject: Re: [PD] table abstractions To: "PD-List" pd-list@iem.at, "Matt Barber" brbrofsvl@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.
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:
- 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
João Pais a écrit :
didn't look at it. quite frankly, I'm not into the "vanilla sport", I guess anyone has enough resources nowadays to cope with pd-ext.
the problem of pd extended is not the resources.
i don't use it for stability / simplicity / compatibility / conservation etc.
Cyrille
If the only non-vanilla object is [arraysize] you can substitute [expr] and make it compatible with pd-vanilla
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
.mmb
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:
- 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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
cyrille henry -
Jonathan Wilkes -
João Pais -
Matt Barber -
Mike Moser-Booth