[PD-dev] Re: pixelTANGO in CVS WAS: Re: [PD] some useful abstractions

Hans-Christoph Steiner hans at eds.org
Mon Feb 27 21:04:19 CET 2006


Ultimately, it sounds like these would be very good candidates for a  
"file" library, i.e. a library of all file related functions.  But as  
I have said earlier, I think we should approach the design of these  
new standard libraries in a top-down way.  We already have a massive  
amount of code built from the bottom-up to draw from.  Now its time  
to design libraries to be consistent and clean, and then port the  
existing code to these new libraries.

This includes pulling out the objects from Pd core.  So things like  
[openpanel] and [savepanel] should probably be in the "file"  
library.   My goal for Pd-0.39.2-extended is to build all of the Pd- 
core objects as a single-file externals in a libdir for backwards  
compatibility, then start porting them to new standardized libraries.

Part of this will also be moving all of the externals/build/src  
objects into their own libdir, so that by default, there will only be  
the very minimal core objects in the root namespace.  Everything else  
will have a lib prefix.  Then preferences files like the current Pd- 
extended ones (org.puredata.pd.plist and pd-settings.reg) can set up  
a backwards-compatible environment.

Ben, want to take on the "file" library?

.hc

On Feb 27, 2006, at 11:01 AM, B. Bogart wrote:

> hi Andres,
>
> I don't have time to try them out now, but they look very nice. I'm
> especially interested in objects.pd what does it do exactly?
>
> Anyhow to the devs, pixelTANGO has a slew of useful abstractions that
> are there only to make the patching of the high-level GOPs easier,
> things like [dirpanel] to choose a directory, and [dirlist] to read  
> all
> files that match a wildcard pattern in a directory and output as a  
> list.
>
> They don't have any help-files yet, so the pixelTANGO GOP abstractions
> are the best documentation on how to use them.
>
> So the question is, since these abstractions work outside of the  
> context
> of pixelTANGO, how should they be included in CVS? Right now they are
> all in the pixelTANGO folder...
>
> As we're talking about redundancy in externals what do you all think
> should be done to reduce the problem of too many redundant  
> abstractions?
>  (specifically excluding such conceptual sets of abstractions, like
> Frank's abstraction reimplimentations of externals)
>
> Just thinking aloud again...
>
> .b.
>
> Andres Ferrari wrote:
>> here, some useful and pedagogical abstractions.
>> acceptance suggestions.
>> enjoy.
>>
>> http://www.puredata.org/Members/anfex
>>
>>
>> soon, some more.
>>
>>
>>
>> __________________________________________________
>> Correo Yahoo!
>> Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
>> Regístrate ya - http://correo.espanol.yahoo.com/
>>
>> _______________________________________________
>> PD-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
>> listinfo/pd-list
>>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list


________________________________________________________________________ 
____

  As we enjoy great advantages from inventions of others, we should  
be glad of an opportunity to serve others by any invention of ours;  
and this we should do freely and generously.
                                                   - Benjamin Franklin





More information about the Pd-dev mailing list