Here is a link to the pdmtl list of files. It has quite a few objects, and a lot of dsp ones too. I am all for adopting this framework, since it is already semi-established with users.
http://wiki.dataflow.ws/PdMtlAbstractions/Contents
Let's face it, it's difficult to find objects through the sorting of author libs right now, since a given author may have a bunch of different abstractions or externals in a sort of hodge-podged bundle. Not all authors do this of course, since we now have separate cvs entries for things like list-abs, etc. Taking from the pdmtl aesthetic would be the next step.
~Kyle
On 6/19/07, Kyle Klipowicz kyleklip@gmail.com wrote:
Another interesting approach is that taken by pdmtl, which uses a namespace-type separation of objects based upon their type and use. IIRC, it is not in Pd-extended yet either...
~Kyle
On 6/19/07, Steffen stffn@dibidut.dk wrote:
On 19/06/2007, at 21.55, Roman Haefeli wrote:
a wiki-page for streamlining the idea and a little howto-guide (with the stuff we already discussed) would be nice, though i don't know how to create the page, respectively who as write acces to it.
I think it's a matter for proposing it to he pdweb list. Alternatively it could go into a README. Thats what they are for, i think.
Question. Will all the object be like: input: control data output: signal/"audio", or will the also be ("audio manipulators") objects like: input: signal/"audio" output: singal/"audio"?
i'd say both, any module that either generates or manipulates audio signals.
Cool. Then that should be added too, i think.
As i see it now, based on the discussion, the lazy-consensus principle, the fact that no one objected against that all abstractions in the lib should have a help file, a README could sound:
This lib, tilde, is focused on dps'ish abstractions that either generates or manipulates audio signals.
To add to the lib either check it into _the_ cvs if you have access or ask someone that have access to check it in for you.
All abstractions in the lib need have a corresponding help file documenting the inlet(s) and outlet(s).
In case your abstraction have dependencies document it somewhere. In case the dependencies are not available anywhere and are in them self abstraction (ie. not externals) add them to a subfolder to not pollute the namespace of the lib.
eh?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
---- -----