Hi Roman,

On Mon, 2008-08-25 at 12:09 +0200, Roman Haefeli wrote:

may ask, why you are asking? i mean, are you simply interested in having a set of pure abstractions for your own use or is there an aim to create a publicly accessible collection?

The reason I ask is that I am working on a project called Integra (www.integralive.org, wiki.integralive.org). We have developed an 'abstraction layer' (libIntegra) for wrapping pieces of functionality in an environment-neutral way, and managing parameter storage. The point of our work is that we don't want to re-invent the wheel wrt the actual processing (we don't want to write another Pd, or ChucK, or Csound, or SuperCollider etc), we just want to leverage existing functionality. Our first proof-of-concept has been done with Pd under-the-hood using our integra_pd_bridge. You can make Integra modules that communicate with libIntegra via the integra_pd_bridge, simply by adding an 'adapter' to an existing Pd patch.

The reason why I asked for existing 'purepd' abstractions, is that we want to start building a library of modules (a module consists of an implementation (the Pd bit), a definition (a fixed set of data *about* the module), and a set of instance data (the module's state, which we store in XML and then in an online database). See also db.integralive.org (very beta!)

I would like to leverage existing work as much as possible, and then feed back into community efforts. At the moment it's looking like we will start by taking some of the pdmtl abstractions and making them 'purepd' if possible. It isn't essential for Integra modules to have no dependencies, but it is encouraged! Then we can feed the work back into the purepd 'project', so everyone can benefit.

Ultimately we will do a similar process with other environments, so that one could load the same Integra 'collection' in SuperCollider, or Pd, so long as the implementations are there.

the idea of creating a 'dsplib' was discussend at least once on this list, but did not end up with someone actually collecting all those abstractions. personally, i decided to contribute my own stuff to pdmtl, since a lot of the work of organizing and structuring such a library is already done there. i found it quite handy, that instead of thinking of any guidelines i could simply follow them.

Yes, pdmtl is a real inspiration. Great project!

otoh, i find it a bit a pitty, that pdmtl has so many dependencies. most of the time, my contributions don't use externals, though. feel free to use all of pdmtl stuff, that doesn't use externals and i would also be willing to assist with removing them in cases, where they are not necessarily needed. if your goal is to create an organized pure pd based and publicly accessible fx library, i could help you with porting my own stuff to your library.

Great! Well I'll be starting this over the next few days, so i'll be in touch as things move forward.

hm.. thinking about that: it actually would be nicer to find a way to flag all purepd stuff of pdmtl instead of porting all the purepd stuff into a new library.

Or maybe the other way around? Perhaps pdmtl could provide 'references' to purepd implementations, rather than holding them in their repository?

Jamie