[PD-dev] extra reorg idea

Hans-Christoph Steiner hans at eds.org
Sat Dec 18 18:30:14 CET 2004


On Dec 17, 2004, at 3:01 AM, zmoelnig at iem.at wrote:

> Zitiere Hans-Christoph Steiner <hans at eds.org>:
>
>>
>> I'd like to propose an idea for organizing all of the objects, instead
>> of placing everything directly in "extra" and "doc/5.reference".
>> Everything that is aimed to be a standard part of Pd would go in
>> "extra" and "5.reference". Then objects that have conflicted names,
>> objects that are deprecated, or cyclone/Max-compatibility objects  
>> would
>> go into their own folders.  When someone wants to use these objects,
>> they can add then directories using -path and -helppath.
>
> correct me if i am wrong:
> 1) let's assume wwe have a libraray "foo", containing of foo.pd_linux  
> and a
> number of help patches foo-help.pd and bar-help.pd;
> _now_ these files are in /usr/lib/pd/extra/:  
> /usr/lib/pd/extra/foo.pd_linux,
> /usr/lib/pd/extra/foo-help.pd and /usr/lib/pd/extra/bar-help.pd
> you _propoese_ them to be in /usr/lib/pd/foo/ or in  
> /usr/lib/pd/extra/foo ??
> - the first solution would impose a bad thing on the usability of pd  
> (in my
> opinion): up till now, you can specify the libraries you want to be  
> loaded in
> the patch itself, without having to hazzle with command-line arguments  
> or
> rc-files: this is ok if you have only one evironment you work with,  
> but if you
> want "several different pds-flavours" (libraries loaded,...) you would  
> need to
> eliminate (or strip down) you rc-file and write quite long .BAT-fies  
> (notice
> that the use of .BAT is on pupose as i really think this is old,  
> clumsy and
> should be deprecated, especially with respect to the new console-less  
> pd)
> - the second solution is already implemented in pd (i think), so  
> people would
> just need to use it (which thy should do anyhow and which makes your  
> proposal
> not at all "useless")
>
> 2) problems with libraries containing mulitple so-files and pd-files  
> are a bit
> more complicated (so i guess you are refereing to that)
> i really think that the solution with giving a lot of path-names is  
> _not_ good,
> because (as mentioned before) we are not (yet ?) able to add things to  
> the
> search-path from within the patch (probably we are, with some weird  
> messages)
> but anyhow, then we would need knowledge about the directory-layout on  
> the
> harddisc which is a bad thing too)
> BUT: using your layout (without adding -path !) would enforce people  
> to use our
> all-time favourite "namespaces" which is indeed a good thing.
>
>
>
> so as a conclusion:
> i think too that libraries should go into separate directories, AND i  
> think that
> these directories should be in pd/extra

I am not thinking at all about libraries because I think that externals  
should be distributed as individual objects, and I plan on making that  
happen in the distros that I work on.  As far as I know, the only  
advantage that libraries currently have is shared code.  I am going to  
try my hand at implementing Günter's idea of having a shared library  
for the shared code, while the objects are in individual files.  Thomas  
Grill was working on this for flext also, I think he got it working.

One thing that I forgot to mention (which you did mention) is that you  
could also use the namespace to access these objects without adding  
anything to the path.  For example, to use a deprecated object you  
would  do this:

[deprecated/linuxjoystick /dev/input/event2]

So putting "../extra/deprecated" in the path would only be for porting  
the patch.  Though this is much less necessary now that 0.38 will  
maintain the connections when an object can't be found.

.hc

________________________________________________________________________ 
____

Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.
Now that he can realize them, he must either change them, or perish.
		                                     -William Carlos Williams





More information about the Pd-dev mailing list