"It looks like the function do_open_via_path in s_path.c is the one to fix..."<br><br>Wow, talk about solving a big problem with the most simple solution!<br>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).
<br><br>Tom<br><br><div><span class="gmail_quote">On 9/18/07, <b class="gmail_sendername"><a href="mailto:martin.peach@sympatico.ca">martin.peach@sympatico.ca</a></b> <<a href="mailto:martin.peach@sympatico.ca">martin.peach@sympatico.ca
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Frank Barknecht wrote:<br>> Hallo,<br>> Georg Holzmann hat gesagt: // Georg Holzmann wrote:
<br>><br>> > As far as I undestood it the code of e.g. comport would go in this<br>> > standard lib (e.g. to hardware/comport) but should not duplicate the<br>> > code - instead the iem/comport code should be obsolete and now
<br>> > maintained in hardware/comport.<br>><br>> Yes, that would be the idea for binaries in the std-lib.<br>><br>> > But as the others convinced me at the pd conv I don't think that this<br>> > will happen soon (and "soon" in pd time means maybe 8-10 years ... ;)
<br>><br>> Depends on how you define "this": I don't think that every external<br>> has to move over to stdlib immediately, if at all. comport would be a<br>> good example for an external that could stay outside the stdlib for
<br>> the next 8-10 years without any bigger problems, as it is an object<br>> with a rather specific purpose. [drip] OTOH would be a candidate to<br>> take immediately. The old build-system by Guenther ("flatspace" in
<br>> pd-extended) already showed the how the whole stdlib could be built as<br>> far as externals are concerned, and abstractions are dead easy to<br>> handle (as long as they are core-Pd-abstractions).<br><br>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].
<br>It looks like the function do_open_via_path in s_path.c is the one to fix...<br><br>Martin<br><br><br>Martin<br><br><br>_______________________________________________<br><a href="mailto:PD-list@iem.at">PD-list@iem.at
</a> mailing list<br>UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br></blockquote></div><br>