[PD-dev] stripping down Pd-extended's default libs

[Hans-Christoph Steiner]

I definitely agree that we should have libraries organized based on a  
topic.  There is nothing stopping anyone from doing this.  There is  
tons of code that could be easily taking and stuck into new libraries  
organized around concepts.

.hc

On Feb 19, 2009, at 1:41 AM, marius schebella wrote:

> wrt the user/patcher distinction:
> ok, let's not differentiate bet. these two. but differentiate  
> between a scenario where you only share patches and abstractions vs.  
> a scenario where you also share library binaries. the first calls  
> for a standardized set of object classes (which does not exist -  
> yet?). with the use of declarations you expect a standardized set of  
> available libraries. but this is future telling, too. to have  
> persistent sharing of pd patches, you either have to agree on a set  
> of object classes or always ship the pd version and libraries.  
> again. declare -lib zexy is also only based on the assumption that  
> we are talking about the same zexy library. this assumption really  
> is not much different than the assumption that we are talking about  
> the same [gate] object class...
>
> wrt pd-extended
> my perception is that the vast majority of pd users use extended.  
> but you are right, there are a lot of situations, where pdx is  
> problematic (the license, then the long startup times(?), some  
> objects (pdj) incompatible...)
>
> wrt to the unsolved object class/library situation
> if we start declaring every object class that we use, then doesn't  
> that mean that we should also separate the pd kernel from the object  
> classes that ship with pd (vanilla) and load -lib vanilla as a  
> (first?) set of available objects?
> the next thing I would strongly propose is a restructuring of the  
> libraries into thematical collections.
> and then deal with the question, if we need libraries at all, why  
> not go with single externals and declare each of them separately.
>
> pd is so much like the real world, unfinished:open  
> imperfect:exciting software:hardware:people:life.
>
> marius.
>
>
> Roman Haefeli wrote:
>> On Tue, 2009-02-17 at 23:30 +0100, marius schebella wrote:
>>> Roman Haefeli wrote:
>>>> On Tue, 2009-02-17 at 11:24 +0100, marius schebella wrote:
>>>>> hey hans,
>>>>>
>>>>> if it's called "extended" and you strip it down to the bare bones,
>>>>> then where's the extended part?
>>>> i think, noone wanted to strip down anything. this is only about  
>>>> not
>>>> loading the whole bunch of libs automatically anymore. how does  
>>>> that
>>>> make pd-extended less 'extended'?
>>> first, I think there is a difference between a "user" user (who  
>>> downloads a patch) and a "patching" user.
>> i think you cannot design a language based on the distinction between
>> several kinds of user groups. the overall goal should be  
>> consistency and
>> i think, what is consistent is the most easy to learn, for_ anyone_.
>> consistency makes it easy for the programmers to program patches  
>> and at
>> the same time 'patch musicians' can rely on those patches to work
>> smoothly.
>> what consistency means in pd world does not seem to be so clear yet,
>> though, but that is why all this talk is necessary.
>>> I always saw pd-extended as a consensual (ok, proposed actually by  
>>> only one person) agreement on a set of object classes that are  
>>> available in addition to pd vanilla. It was a way to make sure  
>>> that if a "patcher" programs a patch for pd-extended that every  
>>> other pd-extended "user" will have the same setup and thus be able  
>>> to open the patch without errors.
>>> if you leave the loading of external(librarie)s to the user user,  
>>> that means, if you allow/force the user to create his/her own  
>>> order of startup libs, you cannot count on this behaviour anymore.
>> right. however, in the ideal pd world (it's not there yet, but i  
>> guess
>> it is going there) the loading order wouldn't matter, because  
>> everything
>> would be loaded only canvas-locally.
>>>>> eventually, I think users should not have to bother with  
>>>>> namespaces at
>>>>> all. I still consider namespace declarations in a visual dataflow
>>>>> programming tool to be a hack.
>>>> can you elaborate that a bit?  to me it looks perfectly normal,  
>>>> that i
>>>> have to at least call the tools, that i am going to use.
>>> ok.
>>> this is a problem of software architecture. where to draw the  
>>> border between what is "given" and what is open. to me object  
>>> classes should be part of the given world, because one, it makes  
>>> coding, teaching, deploying easier, if all patchers were using the  
>>> same set of tools and two, if you create your own screws, then you  
>>> also have to ship the screw drivers (not only declare them).
>>>
>>> I know the pd concept is, not to insist on a predefined set of  
>>> object classes, which of course makes pd more extendible, but with  
>>> this huge overhead of having to hassle with declarations,  
>>> namespaces, which are ok for written programming languages, but  
>>> maybe not for a building block programming tool like pd.
>>>
>>> especially if - like in the case of the pd externals - the  
>>> libraries are arbitrary. (like any categorization system). they  
>>> are not sorted by topics but rather by coders. just think, a new  
>>> pd patcher has to learn that an object was programmed by IOhannes,  
>>> and therefor it is in the zexy library. another one was programmed  
>>> by someone at the IEM, therefore it is part of the iemlib.  
>>> furthermore the name of the libraries can change, the same code  
>>> can become part of two different libraries and some objects do not  
>>> even belong to a library.
>>> if you are consequent in providing your tools, it means that you  
>>> have to ship the particular pd externals together with your patch  
>>> everytime you want to share a patch. because then referring to  
>>> zexy is not enough either, someone else could create a concurring  
>>> external library also called zexy. then what...
>>>
>>> plus, not agreeing on the toolset (set of object names) will  
>>> always cause your own abstractions to be potentially overwritten  
>>> by internal/external object classes, which get loaded instead.
>>>
>>> plus, with some objects it is necessary to load them in advance,  
>>> for example all objects with abbreviations, or some objects that  
>>> enable special features (like the loader for luascripts).
>>>
>>> pd is *not* like c, c++, java, these languages create  
>>> applications, but the way I would like to see pd is, that pd  
>>> programmers don't create standalone pd versions, but only pd  
>>> patches.
>>>
>>> plus, don't expect (pd-x) patchers ever to declare all  
>>> objectclasses that they're using.
>>>
>>> I hate to say this, but standards and specifications can really  
>>> make life easier. the habit to leave many things opens allows  
>>> people to addon a lot of crazy stuff, but it is counterproductive  
>>> from the viewpoint of patch sharing.
>> yo.. i think, you made your point very clear. and generally, i agree
>> very much with you. honestly, i would be very fine with everyone only
>> using pd-extended with the exact same path settings and library  
>> order.
>> if that would be, what everyone would agree on, i could perfectly  
>> live
>> without namespaces and without the need to declare classes. however,
>> people on this list seem to agree, that it is by design not the  
>> best way
>> to assume, what is best for the user, but let the users decide
>> themselves. it seems unlikely that everyone is going to switch to
>> pd-extended soon and quite some people only install what they think  
>> they
>> need. so after all, declaring classes seems the only way to handle  
>> those
>> cases and there seems to be a consensus about it. i even think, that
>> besides all conceptional reasons, the fact, that there seems to be a
>> consensus in the pd community is actually the strong point. i  
>> guess, it
>> is one of the few things, that so many people agree on. roman
>> 	
>> 		
>> ___________________________________________________________ Der  
>> frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo!  
>> Mail: http://mail.yahoo.de



----------------------------------------------------------------------------

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