[PD] inconsistencies with lib names (was: representning classes

[Thomas O Fredericks]

"It looks like the function do_open_via_path in s_path.c is the one to
fix..."

Wow, talk about solving a big problem with the most simple solution!
If this were implemented (and that could be done in one day instead of
years), the rights to Max/Msp would not have to be bought (as this is
clearly the feature that most Max/Msp features adore: to install an
external, simply put it in the external folder, and voilà, done).

Tom

On 9/18/07, martin.peach at sympatico.ca <martin.peach at sympatico.ca> wrote:
>
> Frank Barknecht wrote:
> > Hallo,
> > Georg Holzmann hat gesagt: // Georg Holzmann wrote:
> >
> > > As far as I undestood it the code of e.g. comport would go in this
> > > standard lib (e.g. to hardware/comport) but should not duplicate the
> > > code - instead the iem/comport code should be obsolete and now
> > > maintained in hardware/comport.
> >
> > Yes, that would be the idea for binaries in the std-lib.
> >
> > > But as the others convinced me at the pd conv I don't think that this
> > > will happen soon (and "soon" in pd time means maybe 8-10 years ... ;)
> >
> > Depends on how you define "this": I don't think that every external
> > has to move over to stdlib immediately, if at all. comport would be a
> > good example for an external that could stay outside the stdlib for
> > the next 8-10 years without any bigger problems, as it is an object
> > with a rather specific purpose. [drip] OTOH would be a candidate to
> > take immediately. The old build-system by Guenther ("flatspace" in
> > pd-extended) already showed the how the whole stdlib could be built as
> > far as externals are concerned, and abstractions are dead easy to
> > handle (as long as they are core-Pd-abstractions).
>
> I think it would be more useful right now if pd would search in
> subdirectories. For instance there are about 70 directories in pd/extra (Pd
> version 0.40.3-extended-20070905), and only 10 lines in the path
> dialog...not to mention the time wasted typing in every single path. At the
> moment most of the help files are not found and the objects don't work
> unless they are prefixed with their path, like [mrpeach/oscsend].
> It looks like the function do_open_via_path in s_path.c is the one to
> fix...
>
> Martin
>
>
> Martin
>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20070918/ee50b0ca/attachment.htm>