[PD] 'pure' pd DSP abstractions wanted!

Jamie Bullock jamie at postlude.co.uk
Mon Aug 25 18:45:25 CEST 2008

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?



More information about the Pd-list mailing list