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
Hallo, martin.peach@sympatico.ca hat gesagt: // martin.peach@sympatico.ca wrote:
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...
This might break some stuff. For example I often use "private" subdirectories whose objects should *not* be available globally.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
"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@sympatico.ca martin.peach@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
"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),
If it was implemented, which one would become [once]:
extra/purepd/once.pd extra/iemabs/once.pd extra/pdmtl/flow/once.pd
or maybe:
extra/iem/spatialization/VARESE/app/iemabs/once.pd extra/CUBEmixer/lib/libs/iemabs/once.pd
?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Well, the examples with more than one folder depth are not of concern. Just limit the search to one depth. Also, asking the authors of the conflicting objects/abstractions is much less work than building a mega-meta-system. After, that, the cvs "law" could simply state that no now object/abstraction may have the same name at the first depth level (or second depth depending on your persepective).
So only objetcts/abstractions named extra/*/*.pd, extra/*/*.dll, extra/*/*.pd_linux or extra/*/*.pd_darwin
Also, please quoting pdmtl abstractions. If you require more information about them, please visit the documentation website. The cvs version is outdated, and since there is talking of making a svn system, they will be integrated properly then.
Tom
On 9/18/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
"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),
If it was implemented, which one would become [once]:
extra/purepd/once.pd extra/iemabs/once.pd extra/pdmtl/flow/once.pd
or maybe:
extra/iem/spatialization/VARESE/app/iemabs/once.pd extra/CUBEmixer/lib/libs/iemabs/once.pd
?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
Well, the examples with more than one folder depth are not of concern. Just limit the search to one depth.
Okay, one level could work for "extra". It would break how pd-extended is built however.
Also, asking the authors of the conflicting objects/abstractions is much less work than building a mega-meta-system. After, that, the cvs "law" could simply state that no now object/abstraction may have the same name at the first depth level (or second depth depending on your persepective).
I'm not too confident about this "ask the authors" as that didn't work out in the past (10 years). I think, for Pd a "mechanisms not policy" guideline as the Lua people have works better. Without policy the risk of automatically searching one additional level is that nameclashes are easier again, even with only one level, because extra/a/x.pd and extra/b/x.pd both can exist on one harddisk without problems and we have two [x] again.
So only objetcts/abstractions named extra/*/*.pd, extra/*/*.dll, extra/*/*.pd_linux or extra/*/*.pd_darwin
Also, please quoting pdmtl abstractions. If you require more information about them, please visit the documentation website. The cvs version is outdated, and since there is talking of making a svn system, they will be integrated properly then.
Ah, I'm very sorry. I was only looking at how it's in CVS and pd-extended and now I see that you've dropped the second-level directories.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
martin.peach@sympatico.ca wrote:
I think it would be more useful right now if pd would search in subdirectories.
How about the adding the ability to write an asterix for recursive search so
/home/atte/music/synth/pd/attes_pd_stuff/*
would also look in
/home/atte/music/synth/pd/attes_pd_stuff/externals /home/atte/music/synth/pd/attes_pd_stuff/abstractions /home/atte/music/synth/pd/attes_pd_stuff/midi_instruments
This would keep backwards compatibility + make it possible to do it only for certain directories. I realize the user would still be able to run into name clashes, though...
Hey all,
This is a nice idea, but the bottom line is that its too late for that. People already depend on many old (first) funny externals like Markex Counter, which is still in some of my older patches. Its the oldest counter, so should it be the default? too bad its inlets are arranged differently than its arguments. too late to fix that too.
PixelTANGO also depends on private externals in a subdirectory that should not be available to the end user. (and not just because it depends on memento either)
The libdirs are the solution to that problem, and it has already been solved.
Maybe such a feature would be in PD devel or something for the power users to build there own PD, but I'm moving more and more to pd-extended even for installation stuff and especially now that there are nice debs for it.
Throwing away the way extended works (and namespaces) to get some extra drop an external somewhere solution does not make much sense to me.
As for MaxMSP, if you want to install an external in PD vanilla, just put it in the extra folder, not in a subfolder!!!
How many files are in the Max "extra" (or whatever its called folder?) I think Marius counter over 1200 externals in PD...
I don't see any goo reasons against the way the libdir design now (and should in the future) work. So why not improve that then find more awkward ways around the same problems?
Just my opinion, .b.
Atte André Jensen wrote:
martin.peach@sympatico.ca wrote:
I think it would be more useful right now if pd would search in subdirectories.
How about the adding the ability to write an asterix for recursive search so
/home/atte/music/synth/pd/attes_pd_stuff/*
would also look in
/home/atte/music/synth/pd/attes_pd_stuff/externals /home/atte/music/synth/pd/attes_pd_stuff/abstractions /home/atte/music/synth/pd/attes_pd_stuff/midi_instruments
This would keep backwards compatibility + make it possible to do it only for certain directories. I realize the user would still be able to run into name clashes, though...
-
Atte André Jensen -
B. Bogart -
Frank Barknecht -
martin.peach＠sympatico.ca -
Thomas O Fredericks