Hi, is it true, that only hans is working on the pd-extended releases? are there other maintainers? I got the impression in the past that pd-extended is very useful (and I personally use it a lot), but development for it is also very cryptical and almost hidden like a secret. and often things are implemented that seem to be good ideas, but do not really work (like the whole path/import stuff). maybe hans, if you could provide more information and documentation about pd-extended and how the whole integration of libraries works then more people would be able to help you and development would be more consistent. what is the direction that you want to go? for me pd-extended is the attempt to create a pd distribution that includes as many as possible external libraries in addition to pd vanilla. I love most of the things in pd-ext, although there is still a lot of work that needs to be done... marius.
Lots of people contribute, but I am the person who manages the
releases. Any help is welcome. The path/import/declare stuff is
currently a half-complete effort of Miller's and mine.
Basically up until recently, I was pursing Pd-extended as a proof of
concept for building libraries as standalone binaries in directories
instead of all compiled into one binary. I think that clearly works,
so now it is time to clean things up into a coherent package.
I document what I can here: http://puredata.info/docs/developer/
I don't really know what else needs to be documented. One way to
find out is when people start to contribute, then they find
shortcomings that we can fill in.
.hc
On Apr 15, 2008, at 2:15 PM, marius schebella wrote:
Hi, is it true, that only hans is working on the pd-extended releases? are there other maintainers? I got the impression in the past that pd-extended is very useful
(and I personally use it a lot), but development for it is also very
cryptical and almost hidden like a secret. and often things are implemented that seem to be good ideas, but do not really work (like the whole path/import stuff). maybe hans, if you could provide more information and documentation about pd-extended and how the whole integration of libraries works
then more people would be able to help you and development would be more consistent. what is the direction that you want to go? for me pd-extended is the attempt to create a pd distribution that includes as many as possible external libraries in addition to pd vanilla. I love most of the things in pd-ext, although there is
still a lot of work that needs to be done... marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
Hans-Christoph Steiner wrote:
Lots of people contribute, but I am the person who manages the releases. Any help is welcome. The path/import/declare stuff is currently a half-complete effort of Miller's and mine.
is there a page where this idea is documented? how is it supposed to work in the future? I still don't know. will I have to include declare in every patch that I write???
Basically up until recently, I was pursing Pd-extended as a proof of concept for building libraries as standalone binaries in directories instead of all compiled into one binary. I think that clearly works, so now it is time to clean things up into a coherent package.
It doesn't work for abbreviations.
I document what I can here: http://puredata.info/docs/developer/
thanks.
I don't really know what else needs to be documented. One way to find out is when people start to contribute, then they find shortcomings that we can fill in.
well, it would be nice if there was some documentation of which libraries and objects are included, how to handle all the path problems, which paths and libs are loaded by default how to load the other libs/externals. filessystem layout, platform compatibility, which libraries do *not* work on which os. what additional features you added to pd-extended (advanced helpmenu, advanced tcltk interface (colorscheme...), differences in shortcuts, closing, ..... all that.
marius.
.hc
On Apr 15, 2008, at 2:15 PM, marius schebella wrote:
Hi, is it true, that only hans is working on the pd-extended releases? are there other maintainers? I got the impression in the past that pd-extended is very useful (and I personally use it a lot), but development for it is also very cryptical and almost hidden like a secret. and often things are implemented that seem to be good ideas, but do not really work (like the whole path/import stuff). maybe hans, if you could provide more information and documentation about pd-extended and how the whole integration of libraries works then more people would be able to help you and development would be more consistent. what is the direction that you want to go? for me pd-extended is the attempt to create a pd distribution that includes as many as possible external libraries in addition to pd vanilla. I love most of the things in pd-ext, although there is still a lot of work that needs to be done... marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Hans-Christoph Steiner wrote:
Lots of people contribute, but I am the person who manages the releases. Any help is welcome. The path/import/declare stuff is currently a half-complete effort of Miller's and mine.
is there a page where this idea is documented? how is it supposed to work in the future? I still don't know. will I have to include declare in every patch that I write???
[declare] currently is rather useless. You can load a binary library with [declare], but AFAIK Pd-extended doesn't have any libraries except Gem. [declare -path] acts "funny", or rather, it's unclear whether it should act differently when used in an abstraction instance compared to being used standalone.
Directory prefixes like [zexy/abs~] kind of solve the problem. The problem is, that nobody likes them. (Though probably Hans does;) E.g. I remember that you were complaining quite loudly when the new pd-extended version didn't preload many libraries and libdirs. But of course preloading libraries makes the [zexy/abs~] approach pointless, except for objects in private or rarely used libraries.
OTOH the names of the directories in CVS have been chosen to be the names of the prefixes, which is something, several developers didn't like, but some way to name the subdires had to be chosen of course. Example: Martin doesn't like [mrpeach/packOSC], I don't like the redundant [list-abs/list-abs] etc.
But the real problem is this: Advertising the libdir directories as namespaces has created hundreds of possible new object names. Of course people use these new names, and now backwards compatibility has to take these new names into account. Any "pd-condensed" which I recently invented as a joke would still need to support these new names (or just ignore them). And if some future, cleaned up version of pd-extended includes [abs~] globally, it also will need to offer support for [zexy/abs~], [creb/abs~], [markex/abs~] and [flatspace/abs~] to not break patches written in the advertised style. Not very beautiful.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Hans-Christoph Steiner wrote:
Lots of people contribute, but I am the person who manages the releases. Any help is welcome. The path/import/declare stuff is currently a half-complete effort of Miller's and mine.
is there a page where this idea is documented? how is it supposed to work in the future? I still don't know. will I have to include declare in every patch that I write???
[declare] currently is rather useless. You can load a binary library with [declare], but AFAIK Pd-extended doesn't have any libraries except Gem. [declare -path] acts "funny", or rather, it's unclear whether it should act differently when used in an abstraction instance compared to being used standalone.
there are some other libraries that are still bundled binaries, pdp for example. I think declare -lib works relative to the abstraction. but you also have to possibility to use -stdlib which will be relative to pd or use absolute paths.
Directory prefixes like [zexy/abs~] kind of solve the problem. The problem is, that nobody likes them. (Though probably Hans does;) E.g. I remember that you were complaining quite loudly when the new pd-extended version didn't preload many libraries and libdirs. But of course preloading libraries makes the [zexy/abs~] approach pointless, except for objects in private or rarely used libraries.
I totally agree with you that preloading unnecessary libraries is a waste of memory. there are only two cases where you really have to do that: bundled libraries and objects that have abbreviated names. if you don't preload them, they will not work. with the rest of the objectclasses I think it should be enough to load the path, which would only load the classes into memory, after you created an object (and then only load this single object. correct?
still don't know what to do about abbreviated objectnames. maybe the meta file can handle this?
marius.
OTOH the names of the directories in CVS have been chosen to be the names of the prefixes, which is something, several developers didn't like, but some way to name the subdires had to be chosen of course. Example: Martin doesn't like [mrpeach/packOSC], I don't like the redundant [list-abs/list-abs] etc.
But the real problem is this: Advertising the libdir directories as namespaces has created hundreds of possible new object names. Of course people use these new names, and now backwards compatibility has to take these new names into account. Any "pd-condensed" which I recently invented as a joke would still need to support these new names (or just ignore them). And if some future, cleaned up version of pd-extended includes [abs~] globally, it also will need to offer support for [zexy/abs~], [creb/abs~], [markex/abs~] and [flatspace/abs~] to not break patches written in the advertised style. Not very beautiful.
Ciao
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Frank Barknecht wrote:
Directory prefixes like [zexy/abs~] kind of solve the problem. The problem is, that nobody likes them. (Though probably Hans does;) E.g. I remember that you were complaining quite loudly when the new pd-extended version didn't preload many libraries and libdirs. But of course preloading libraries makes the [zexy/abs~] approach pointless, except for objects in private or rarely used libraries.
I totally agree with you that preloading unnecessary libraries is a waste of memory.
Actually I wasn't referring to preloading and I don't care about the memory waste (which is minor), but to the "virtual library loading" that pd-extended does with its libdir loading or path settings. IIRC that was, what you and many others were complaing about when it was broken on their systemsa.
Most of the libraries in pd-extended are built as single externals, and for abstraction libraries like list-abs bundles aren't possible anyway.
Ciao
Frank Barknecht
sorry, I still don't know exactly what you mean. I think it is the only solution to keep libraries in subfolders if we want to solve nameclashes. but even if in subfolders, they should be accessible as list-abs and not list-abs/list-abs. the thing that I was complaining so loudly is that pd-extended ships all these libraries but does not add the paths. (and pd does not look into the sub-directories of extra). and there is no way to add the paths except writing them into the plist manually. marius.
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Frank Barknecht wrote:
Directory prefixes like [zexy/abs~] kind of solve the problem. The problem is, that nobody likes them. (Though probably Hans does;) E.g. I remember that you were complaining quite loudly when the new pd-extended version didn't preload many libraries and libdirs. But of course preloading libraries makes the [zexy/abs~] approach pointless, except for objects in private or rarely used libraries.
I totally agree with you that preloading unnecessary libraries is a waste of memory.
Actually I wasn't referring to preloading and I don't care about the memory waste (which is minor), but to the "virtual library loading" that pd-extended does with its libdir loading or path settings. IIRC that was, what you and many others were complaing about when it was broken on their systemsa.
Most of the libraries in pd-extended are built as single externals, and for abstraction libraries like list-abs bundles aren't possible anyway.
Ciao
Hallo, marius schebella hat gesagt: // marius schebella wrote:
sorry, I still don't know exactly what you mean. I think it is the only solution to keep libraries in subfolders if we want to solve nameclashes. but even if in subfolders, they should be accessible as list-abs and not list-abs/list-abs.
Huh? Nameclashes have nothing to do with subfolders per se. A nameclash is, when two objects have the same name registered in Pd but act differently. Folders are a way to organize files in a filesystem (harddisk).
the thing that I was complaining so loudly is that pd-extended ships all these libraries but does not add the paths.
Yes, that's exactly what I mean: Many people would like every objectclass to be global. OTOH many also want every object in CVS to be available in pd-extended. The net result then is a lot of nameclashes: You just cannot get zexy's urn and maxlib's urn loaded into the global namespace at the same time without a clash. (Actually you cannot even load them at the same time at all, IIR.)
Ciao
Frank Barknecht
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
sorry, I still don't know exactly what you mean. I think it is the only solution to keep libraries in subfolders if we want to solve nameclashes. but even if in subfolders, they should be accessible as list-abs and not list-abs/list-abs.
Huh? Nameclashes have nothing to do with subfolders per se. A nameclash is, when two objects have the same name registered in Pd but act differently. Folders are a way to organize files in a filesystem (harddisk).
the thing that I was complaining so loudly is that pd-extended ships all these libraries but does not add the paths.
Yes, that's exactly what I mean: Many people would like every objectclass to be global.
but that is not a problem for pd-extended users (and I want to solve the pd-extended problems here), as long as you can overrule the global namespace with a local namespace. pd-extended would provide a default object for every nameclash. If you have old patches that were using objects, that are not the default in pd-extended you would have to add a declare to your patch. or explicitely call them as mynondefaultlib/abs~. am I wrong? marius.
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
sorry, I still don't know exactly what you mean. I think it is the only solution to keep libraries in subfolders if we want to solve nameclashes. but even if in subfolders, they should be accessible as list-abs and not list-abs/list-abs.
Huh? Nameclashes have nothing to do with subfolders per se. A nameclash is, when two objects have the same name registered in Pd but act differently. Folders are a way to organize files in a filesystem (harddisk).
the thing that I was complaining so loudly is that pd-extended ships all these libraries but does not add the paths.
Yes, that's exactly what I mean: Many people would like every objectclass to be global.
but that is not a problem for pd-extended users (and I want to solve the pd-extended problems here), as long as you can overrule the global namespace with a local namespace.
Not really: Say I use [urn] in Pd-extended. Which [urn] am I using?
As pd-extended by popular demand (and for practical reasons) is configured to allow access to one of the [urn]s out of the box, I believe not many people are actually using the names [zexy/urn] or [maxlib/urn] or [cyclone/urn]. But all of these behave differently. So we have a hidden nameclash if you try to use a patch that assumes [urn] to be the one from the library, pd-extended loads as the second one. Now IIRC Hans' goal is to not load any library or set any path out of the box, so that all names would have to be qualified with directory prefixes or [declare]d. But when this behavious accidentally came into effect because of the change in plist-location on OS-X, people complained about missing objects and that their patches were broken with the new pd-extended. Note that I don't want to rate if they complained for a good reason, I just want to point to a problem.
pd-extended would provide a default object for every nameclash. If you have old patches that were using objects, that are not the default in pd-extended you would have to add a declare to your patch. or explicitely call them as mynondefaultlib/abs~.
So you see: pd-extended selected a certain set of externals to be the default set of available objectclasses in pd-extended. I don't know how it was decided which libs should be these defaults, I don't even know which ones are the defaults. Probably Hans just chose some popular ones, which is a sensible thing to do.
In the long run, this process should become a bit more organized and it especially should not be handled along library/author borders. For example, I think, zexy (rightfully) has a high loading priority, because it's one of the oldest and most widely used library. But Cyclone also deserves a high priority because it's generally Max-compatible. OTOH zexy is older. What to do? If we only priorize complete libraries, we're not able to make finely grained decisions about single objects. Maybe zexy's [abs~] is better, while [urn] in Cyclone is preferable.
In the end we may be back at square one: a "flatspace" with the selected best of the (un)pack objectclasses in a single directory. No problems with path settings, all is fine again.
Or what am I missing? ;)
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
the thing that I was complaining so loudly is that pd-extended ships all these libraries but does not add the paths.
Yes, that's exactly what I mean: Many people would like every objectclass to be global.
but that is not a problem for pd-extended users (and I want to solve the pd-extended problems here), as long as you can overrule the global namespace with a local namespace.
Not really: Say I use [urn] in Pd-extended. Which [urn] am I using?
all people interested in pd-extended would have influence on the order, like hans, you, me... we would provide a list with all nameclashes inherent in pd-extended and how to access the non default classes. (at least that is my intention.)
As pd-extended by popular demand (and for practical reasons) is configured to allow access to one of the [urn]s out of the box, I believe not many people are actually using the names [zexy/urn] or [maxlib/urn] or [cyclone/urn]. But all of these behave differently. So we have a hidden nameclash if you try to use a patch that assumes [urn] to be the one from the library, pd-extended loads as the second one.
additionaly we could have a printout everytime you try to load a class that is in a nameclash with another one the sonsole, but that would be annoying too, no?
Now IIRC Hans' goal is to not load any library or set any path out of the box, so that all names would have to be qualified with directory prefixes or [declare]d.
yes, but I think it *should* be set out of the box.
pd-extended would provide a default object for every nameclash. If you have old patches that were using objects, that are not the default in pd-extended you would have to add a declare to your patch. or explicitely call them as mynondefaultlib/abs~.
So you see: pd-extended selected a certain set of externals to be the default set of available objectclasses in pd-extended. I don't know how it was decided which libs should be these defaults, I don't even know which ones are the defaults. Probably Hans just chose some popular ones, which is a sensible thing to do.
noone knows which objectclasses are loaded by default, and nobody ever decided this, everything is arbitrary, but I have not given up the hope that this will change soon. if you have this published list of objects that pd-extended uses and want to write your own abstractions, then you would have a good reference of taken names, and this will prevent further nameclashes in the future. more people would focus on *one* list of available pd objects and name their abstractions in reference to the already existing ones.
In the long run, this process should become a bit more organized
my words...
it especially should not be handled along library/author borders. For example, I think, zexy (rightfully) has a high loading priority, because it's one of the oldest and most widely used library. But Cyclone also deserves a high priority because it's generally Max-compatible. OTOH zexy is older. What to do? If we only priorize complete libraries, we're not able to make finely grained decisions about single objects. Maybe zexy's [abs~] is better, while [urn] in Cyclone is preferable.
how many nameclashes do we have? 20, 30? how many libraries are affected 5? yea, that's what has to be done. the situation right now is worse than any solution with a default class. because an object like urn is already problematic. a mentored "quasi-official" pd-objectclass list would at least guarantee future compatibility for the one class that would be considered the default. and the other urns would have to be explicitely called with notdefault/urn. but that is exactly what needs to be done to prevent nameclashes. if you don't do it, then you never will have compatibility...
marius.
On Wed, 2008-04-16 at 15:48 -0400, marius schebella wrote:
how many nameclashes do we have? 20, 30? how many libraries are affected 5? yea, that's what has to be done. the situation right now is worse than any solution with a default class. because an object like urn is already problematic. a mentored "quasi-official" pd-objectclass list would at least guarantee future compatibility for the one class that would be considered the default. and the other urns would have to be explicitely called with notdefault/urn. but that is exactly what needs to be done to prevent nameclashes. if you don't do it, then you never will have compatibility...
how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals.
not only this, but also for a patch dev it can be quite a pain to make a patch work on both using [declare], because in one case you need -stdpath and in the other -stdlib. in the end you are forced to use always both for no good reason.
i think it is not up to me to ask such questions, but wouldn't it be generally better, if the multiple-class-per-external format would be simply dropped? this would also have the nice side effect, that noone would ever use aliasses anymore, which currently (and in the future?) aren't fully supported.
from what i can tell, making a patch work exactly the same on extended and vanilla adds quite some overhead. or is it only me, who would like to create portable (between vanilla and extended) patches?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Apr 16, 2008, at 6:15 PM, Roman Haefeli wrote:
On Wed, 2008-04-16 at 15:48 -0400, marius schebella wrote:
how many nameclashes do we have? 20, 30? how many libraries are
affected 5? yea, that's what has to be done. the situation right now is worse than any solution with a default
class. because an object like urn is already problematic. a mentored "quasi-official" pd-objectclass list would at least guarantee future compatibility for the one class that would be considered the default. and the other urns would have to be explicitely called with
notdefault/urn. but that is exactly what needs to be done to prevent nameclashes.
if you don't do it, then you never will have compatibility...how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals.
not only this, but also for a patch dev it can be quite a pain to
make a patch work on both using [declare], because in one case you need -stdpath and in the other -stdlib. in the end you are forced to use always both for no good reason.i think it is not up to me to ask such questions, but wouldn't it be generally better, if the multiple-class-per-external format would be simply dropped? this would also have the nice side effect, that noone would ever use aliasses anymore, which currently (and in the future?) aren't fully supported.
This sounds great to me, but this is probably no surprise! :)
.hc
from what i can tell, making a patch work exactly the same on extended and vanilla adds quite some overhead. or is it only me, who would like to create portable (between vanilla and extended) patches?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo!
Mail: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
Roman Haefeli wrote:
how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals.
seriously??? I did not know that. that actually changes a lot. it basically means "back to start"...
not only this, but also for a patch dev it can be quite a pain to make a patch work on both using [declare], because in one case you need -stdpath and in the other -stdlib. in the end you are forced to use always both for no good reason.
i think it is not up to me to ask such questions, but wouldn't it be generally better, if the multiple-class-per-external format would be simply dropped? this would also have the nice side effect, that noone would ever use aliasses anymore, which currently (and in the future?) aren't fully supported.
what are aliases? and what are multiple-class-per-externals? do you mean the bundled libraries or the split-into-separate-files libraries
from what i can tell, making a patch work exactly the same on extended and vanilla adds quite some overhead. or is it only me, who would like to create portable (between vanilla and extended) patches?
it should be 100% compatible and should add no or only the very minimum necessary overhead. I am willing to put a lot of effort into this being realized.
marius.
On Wed, 2008-04-16 at 22:54 -0400, marius schebella wrote:
Roman Haefeli wrote:
how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals.
seriously??? I did not know that. that actually changes a lot. it basically means "back to start"...
pd-extended: extra/zexy/abs~.pd_linux: 'abs~' can be called by [zexy/abs~] pd-vanilla: extra/zexy.pd_linux: [zexy/abs~] doesn't work
not only this, but also for a patch dev it can be quite a pain to make a patch work on both using [declare], because in one case you need -stdpath and in the other -stdlib. in the end you are forced to use always both for no good reason.
i think it is not up to me to ask such questions, but wouldn't it be generally better, if the multiple-class-per-external format would be simply dropped? this would also have the nice side effect, that noone would ever use aliasses anymore, which currently (and in the future?) aren't fully supported.
what are aliases? and what are multiple-class-per-externals? do you mean the bundled libraries or the split-into-separate-files libraries
[mux] is an alias od [multiplex]. currently [mux] can only be instantiated when a [multiplex] has been instantiated before. which means that aliases are not fully supported by the libdir format.
sorry for causing confusion with new terms. when saying 'multiple-class-per-external format' i was referring to the bundled libraries. let's stick with the latter.
from what i can tell, making a patch work exactly the same on extended and vanilla adds quite some overhead. or is it only me, who would like to create portable (between vanilla and extended) patches?
it should be 100% compatible and should add no or only the very minimum necessary overhead. I am willing to put a lot of effort into this being realized.
cool to hear.
here a list of a few issues regarding portability between extended and vanilla, that i encountered while using netpd:
objects, that use the alias name ([mux], [l2s], [s2l] etc.) cannot often not be created, when a patch is loaded on pd-extended. possible work-arounds: - avoid alias-names when making a netpd-patch(my recommended solution) - loading a patch which calls all objects with aliases by their original name, so that the aliasses work afterwards
certain classes cause troubles because they contain characters, that aren't supported by the filesystem (is the filesystem the real reason?) however, certain classes, such as [<~] and [<~] cannot be used at all in pd-extended. my recommended workaround: - avoid such classes in netpd-patches
since it cannot be expected, that every pd-user uses the same configuration (i.e. pd-settings file/registry), it seemed reasonable to me, that netpd loads dependencies by itself. the introduction of [declare] looked very promising at first glance, because it should make it possible, that each patch can load its own dependencies independently from a specific configuration file. currently there are still some culprits with that approach:
- [declare] is partially broken (undecided behaviour inside abstractions)
- i have to use a different [declare] for pd-extended than for pd- vanilla: [declare -stdlib zexy] vs. [declare -stdpath zexy]
- some libraries are called differently on both: iemlib vs. iemlib1, iemlib2, iem_t3_lib, iemabs
workarounds: none if a netpd-patch developer wants to make her patch work on all pd distros, she needs to be aware of the different layouts, which is an unnecessary overhead, i believe.
replace 'netpd' by any project, that focusses on portability.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
pd-extended: extra/zexy/abs~.pd_linux: 'abs~' can be called by [zexy/abs~] pd-vanilla: extra/zexy.pd_linux: [zexy/abs~] doesn't work
I really want to avoid ever writing [zexy/abs~] as an object. if I wanted to explicitely use a certain version of abs~ then it should be included by [declare -lib zexy/abs~] but I think this would not work in vanilla either. well, it cannot work in vanilla, because vanilla does not ship with zexy. so, what you are saying is, [declare -lib zexy/abs~] does not work on everybody's system. but then, people who run a home-brewed pd-version other than pd-extended will see the error on their console and hopefuly know what to do. they would have even worse problems, if they did not get an error and were using the wrong abs~ (although I cannot think of another behaviour for abs~). my idea is really that all objects can be created with [classname] without prefixes. then we only have to worry about nameclashes.
what is the current policy with abstractions vs. externals? which one are picked first?
not only this, but also for a patch dev it can be quite a pain to make a patch work on both using [declare], because in one case you need -stdpath and in the other -stdlib. in the end you are forced to use always both for no good reason.
i think it is not up to me to ask such questions, but wouldn't it be generally better, if the multiple-class-per-external format would be simply dropped? this would also have the nice side effect, that noone would ever use aliasses anymore, which currently (and in the future?) aren't fully supported.
what are aliases? and what are multiple-class-per-externals? do you mean the bundled libraries or the split-into-separate-files libraries
[mux] is an alias od [multiplex]. currently [mux] can only be instantiated when a [multiplex] has been instantiated before. which means that aliases are not fully supported by the libdir format.
yes, maybe there is a chance to include this information in the metafile? although this would mean a lot of extra work. in general I am *for* aliases, because they make patching faster and use less space.
here a list of a few issues regarding portability between extended and vanilla, that i encountered while using netpd:
- objects, that use the alias name ([mux], [l2s], [s2l] etc.) cannot often not be created, when a patch is loaded on pd-extended. possible work-arounds: - avoid alias-names when making a netpd-patch(my recommended solution) - loading a patch which calls all objects with aliases by their original name, so that the aliasses work afterwards
in the long-run I hope aliases will be supported by pd-extended. right now this is a pain. if you create the objects once with their full name (maybe in a subpatch) then you can use the aliases. but that's also a bad workaround and potential source of bugs
- certain classes cause troubles because they contain characters, that aren't supported by the filesystem (is the filesystem the real reason?) however, certain classes, such as [<~] and [<~] cannot be used at all in pd-extended. my recommended workaround: - avoid such classes in netpd-patches
I think this is a bug, because this was possible earlier, no? It is not possible to avoid >~. the hexloader stuff is broken on osx.
- since it cannot be expected, that every pd-user uses the same configuration (i.e. pd-settings file/registry), it seemed reasonable to me, that netpd loads dependencies by itself. the introduction of [declare] looked very promising at first glance, because it should make it possible, that each patch can load its own dependencies independently from a specific configuration file. currently there are still some culprits with that approach:
workarounds: none
- [declare] is partially broken (undecided behaviour inside abstractions)
- i have to use a different [declare] for pd-extended than for pd- vanilla: [declare -stdlib zexy] vs. [declare -stdpath zexy]
- some libraries are called differently on both: iemlib vs. iemlib1, iemlib2, iem_t3_lib, iemabs
again, I think all these objects should be available in pd-extended without the need of further declares.
if a netpd-patch developer wants to make her patch work on all pd distros, she needs to be aware of the different layouts, which is an unnecessary overhead, i believe.replace 'netpd' by any project, that focusses on portability.
thanks for putting together this very good list of problems. can we give the broken hexloader and declare a "high priority" in the bug tracker?
marius.
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals.
This problem is not related to multiclass externals (i.e. bundles) at all: All patches that use a directory prefix to specify object names break as soon as that directory name isn't available because it doesn't exist.
As pd-vanilla doesn't have most of the subdirectories in extra, that pd-extended does, and as there is no common installer just for externals yet, people who install their own externals may have them in whatever directory. It all depends on their paths settings.
Ciao
Frank Barknecht
On Thu, 2008-04-17 at 08:26 +0200, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals.
This problem is not related to multiclass externals (i.e. bundles) at all: All patches that use a directory prefix to specify object names break as soon as that directory name isn't available because it doesn't exist.
hm...does that mean, when there is:
extra/zexy/zexy.pd_linux
[zexy/abs~] could be instantiated? i tried and it didn't work. i must be misunderstanding you. for bundles, even if there is a directory prefix, [mylib/myabs] doesn't work.
As pd-vanilla doesn't have most of the subdirectories in extra, that pd-extended does, and as there is no common installer just for externals yet, people who install their own externals may have them in whatever directory. It all depends on their paths settings.
i don't see an advantage in the user being responsible where to put dependencies. why cannot we come up with a standard? how will it be possible to create portable patches independently from some user-edited configuration file? as others already pointed out, other programming languages use standards and a script/programm will run on every system, that has the dependencies installed. there is no need for the user to tweak the configuration or adapt the script. don't we want to get at this point as well?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
hm...does that mean, when there is:
extra/zexy/zexy.pd_linux
[zexy/abs~] could be instantiated? i tried and it didn't work. i must be misunderstanding you. for bundles, even if there is a directory prefix, [mylib/myabs] doesn't work.
Yes, you're right, I wasn't thinking of this actually.
Ciao
Frank Barknecht _ ______footils.org__
Roman Haefeli wrote:
On Wed, 2008-04-16 at 15:48 -0400, marius schebella wrote:
how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals.
at the beginning of this discussion (probably 2002 or so; i have no idea) i posted a diff for Pd that would allow this: using [mylib/myclass] after loading the multiclass-library "mylib" containing the class "myclass".
the patch never got accepted (iirc, the arguing was that nameclashes have to be solved on a social level rather than on a technical one)
i think it is not up to me to ask such questions, but wouldn't it be generally better, if the multiple-class-per-external format would be simply dropped? this would also have the nice side effect, that noone would ever use aliasses anymore, which currently (and in the future?) aren't fully supported.
i think "generally better" would be to drop external support entirely from Pd; this would reduce nameclashes a lot; i don't know how to solve nameclashes of abstractions (without dropping abstraction support), but one idea would be to just not distribute any collections (like Pd-extended) anymore, and make the problem a _private_ one.
but i think we all agree that this is not going to happen.
anyhow, feel free to make Gem a single object per file library :-)
fgmasdr IOhannes
IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
On Wed, 2008-04-16 at 15:48 -0400, marius schebella wrote:
how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals.
at the beginning of this discussion (probably 2002 or so; i have no idea) i posted a diff for Pd that would allow this: using [mylib/myclass] after loading the multiclass-library "mylib" containing the class "myclass".
the patch never got accepted (iirc, the arguing was that nameclashes have to be solved on a social level rather than on a technical one)
and obviously it has the same problems as frank has already mentioned: if the library get's renamed, you cannot access the object anymore.
iirc, there have been more library renames than object-renames in the past.
fgmasdr IOhannes
On Thu, 2008-04-17 at 09:48 +0200, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
On Wed, 2008-04-16 at 15:48 -0400, marius schebella wrote:
how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals.
at the beginning of this discussion (probably 2002 or so; i have no idea) i posted a diff for Pd that would allow this: using [mylib/myclass] after loading the multiclass-library "mylib" containing the class "myclass".
the patch never got accepted (iirc, the arguing was that nameclashes have to be solved on a social level rather than on a technical one)
if i would have known, that this would be possible and that a patch is _already_ written, i probably wouldn't have suggested to drop the multiclass external format. right now i think, your (obviously old) idea seems to be a very good solution. too bad, that it didn't make it into miller's pd.
anyhow, feel free to make Gem a single object per file library :-)
gotcha. i haven't thought about that.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Apr 16, 2008, at 2:58 PM, Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
sorry, I still don't know exactly what you mean. I think it is
the only solution to keep libraries in subfolders if we want to solve nameclashes. but even if in subfolders, they should be
accessible as list-abs and not list-abs/list-abs.Huh? Nameclashes have nothing to do with subfolders per se. A
nameclash is, when two objects have the same name registered in Pd but act differently. Folders are a way to organize files in a filesystem (harddisk).the thing that I was complaining so loudly is that pd-extended
ships all these libraries but does not add the paths.Yes, that's exactly what I mean: Many people would like every objectclass to be global.
but that is not a problem for pd-extended users (and I want to
solve the pd-extended problems here), as long as you can overrule the global namespace with a local namespace.Not really: Say I use [urn] in Pd-extended. Which [urn] am I using?
As pd-extended by popular demand (and for practical reasons) is configured to allow access to one of the [urn]s out of the box, I believe not many people are actually using the names [zexy/urn] or [maxlib/urn] or [cyclone/urn]. But all of these behave differently. So we have a hidden nameclash if you try to use a patch that assumes [urn] to be the one from the library, pd-extended loads as the second one. Now IIRC Hans' goal is to not load any library or set any path out of the box, so that all names would have to be qualified with directory prefixes or [declare]d. But when this behavious accidentally came into effect because of the change in plist-location on OS-X, people complained about missing objects and that their patches were broken with the new pd-extended. Note that I don't want to rate if they complained for a good reason, I just want to point to a problem.
pd-extended would provide a default object for every nameclash. If you have old patches that were using objects, that are not the default in pd-extended you would have to add a declare to your
patch. or explicitely call them as mynondefaultlib/abs~.So you see: pd-extended selected a certain set of externals to be the default set of available objectclasses in pd-extended. I don't know how it was decided which libs should be these defaults, I don't even know which ones are the defaults. Probably Hans just chose some popular ones, which is a sensible thing to do.
In the long run, this process should become a bit more organized and it especially should not be handled along library/author borders. For example, I think, zexy (rightfully) has a high loading priority, because it's one of the oldest and most widely used library. But Cyclone also deserves a high priority because it's generally Max-compatible. OTOH zexy is older. What to do? If we only priorize complete libraries, we're not able to make finely grained decisions about single objects. Maybe zexy's [abs~] is better, while [urn] in Cyclone is preferable.
In the end we may be back at square one: a "flatspace" with the selected best of the (un)pack objectclasses in a single directory. No problems with path settings, all is fine again.
Or what am I missing? ;)
The flatspace model breaks down when you start adding libraries to Pd-
extended. Then you can have nameclashes again. Say someone writes
their own library with an [urn], then what happens? At best,
confusion ensues.
If we look at other programming languages, we can see that namespaces
are a very common solution to this problem (C++, Tcl, python, Java,
Smalltalk, etc). I see no reason why it wouldn't work for Pd as well.
.hc
There is no way to peace, peace is the way. -A.J. Muste
Python's namespacing has these features that I haven't seen discussed yet:
There are three common ways to import: "import list-abs", which just makes list-abs available for use, but you still need to type "list-abs.list-map" (the Python equivalent of [list-abs/list-map]). [1]
"from list-abs import list-map", makes it possible to just type "list-map".
And finally "from list-abs import *", makes it possible to type any of the functions in list-abs without a prefix.
The 3rd option is widely discouraged, because it makes it very unclear where a function comes from, or which one is in use.
I greatly appreciate this arrangement, and I think it would be wise to follow.
A 4th feature that reduces verbosity is the ability to write "import list-abs as l". And of course once things actually work, [list-map] could be renamed to just "map" to give [l/map], which I think is great.
Cheers Luke
On Wed, Apr 16, 2008 at 2:55 PM, Hans-Christoph Steiner hans@eds.org wrote:
On Apr 16, 2008, at 2:58 PM, Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
sorry, I still don't know exactly what you mean. I think it is the only solution to keep libraries in subfolders if we want to solve nameclashes. but even if in subfolders, they should be accessible as list-abs and not list-abs/list-abs.
Huh? Nameclashes have nothing to do with subfolders per se. A nameclash is, when two objects have the same name registered in Pd but act differently. Folders are a way to organize files in a filesystem (harddisk).
the thing that I was complaining so loudly is that pd-extended ships all these libraries but does not add the paths.
Yes, that's exactly what I mean: Many people would like every objectclass to be global.
but that is not a problem for pd-extended users (and I want to solve the pd-extended problems here), as long as you can overrule the global namespace with a local namespace.
Not really: Say I use [urn] in Pd-extended. Which [urn] am I using?
As pd-extended by popular demand (and for practical reasons) is configured to allow access to one of the [urn]s out of the box, I believe not many people are actually using the names [zexy/urn] or [maxlib/urn] or [cyclone/urn]. But all of these behave differently. So we have a hidden nameclash if you try to use a patch that assumes [urn] to be the one from the library, pd-extended loads as the second one. Now IIRC Hans' goal is to not load any library or set any path out of the box, so that all names would have to be qualified with directory prefixes or [declare]d. But when this behavious accidentally came into effect because of the change in plist-location on OS-X, people complained about missing objects and that their patches were broken with the new pd-extended. Note that I don't want to rate if they complained for a good reason, I just want to point to a problem.
pd-extended would provide a default object for every nameclash. If you have old patches that were using objects, that are not the default in pd-extended you would have to add a declare to your patch. or explicitely call them as mynondefaultlib/abs~.
So you see: pd-extended selected a certain set of externals to be the default set of available objectclasses in pd-extended. I don't know how it was decided which libs should be these defaults, I don't even know which ones are the defaults. Probably Hans just chose some popular ones, which is a sensible thing to do.
In the long run, this process should become a bit more organized and it especially should not be handled along library/author borders. For example, I think, zexy (rightfully) has a high loading priority, because it's one of the oldest and most widely used library. But Cyclone also deserves a high priority because it's generally Max-compatible. OTOH zexy is older. What to do? If we only priorize complete libraries, we're not able to make finely grained decisions about single objects. Maybe zexy's [abs~] is better, while [urn] in Cyclone is preferable.
In the end we may be back at square one: a "flatspace" with the selected best of the (un)pack objectclasses in a single directory. No problems with path settings, all is fine again.
Or what am I missing? ;)
The flatspace model breaks down when you start adding libraries to Pd- extended. Then you can have nameclashes again. Say someone writes their own library with an [urn], then what happens? At best, confusion ensues.
If we look at other programming languages, we can see that namespaces are a very common solution to this problem (C++, Tcl, python, Java, Smalltalk, etc). I see no reason why it wouldn't work for Pd as well.
.hc
There is no way to peace, peace is the way. -A.J. Muste
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Apr 16, 2008, at 6:27 PM, Luke Iannini (pd) wrote:
Python's namespacing has these features that I haven't seen
discussed yet:There are three common ways to import: "import list-abs", which just makes list-abs available for use, but you still need to type "list-abs.list-map" (the Python equivalent of [list-abs/list-map]). [1]
"from list-abs import list-map", makes it possible to just type
"list-map".And finally "from list-abs import *", makes it possible to type any of the functions in list-abs without a prefix.
The 3rd option is widely discouraged, because it makes it very unclear where a function comes from, or which one is in use.
I greatly appreciate this arrangement, and I think it would be wise
to follow.
Those sound reasonable, but a lot more work to implement. For the
next release, there should be
- [list-abs/list-split] (like python without needed the "import list-
abs" statement). I am not sure I see the reason to have to import a
lib in order to use it with the lib prefix.
- [import list-abs] which is the same as "from list-abs import *",
for better or worse. It's what Pd people are used to, so...
- I think it should be possible to do [import list-abs/list-split]
but I haven't looked at it too much yet.
A 4th feature that reduces verbosity is the ability to write "import list-abs as l". And of course once things actually work, [list-map] could be renamed to just "map" to give [l/map], which I think is great.
This sounds like a write-only feature, it makes the code much harder
for others to read. If you don't recognize a library name, then you
have to check both whether it is an alias, and if it is a library.
From what I have seen, aliases cause more harm than good in
programming languages.
.hc
Cheers Luke
On Wed, Apr 16, 2008 at 2:55 PM, Hans-Christoph Steiner
hans@eds.org wrote:On Apr 16, 2008, at 2:58 PM, Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
sorry, I still don't know exactly what you mean. I think it is the only solution to keep libraries in subfolders if we want to solve nameclashes. but even if in subfolders, they should be accessible as list-abs and not list-abs/list-abs.
Huh? Nameclashes have nothing to do with subfolders per se. A nameclash is, when two objects have the same name registered in Pd but act differently. Folders are a way to organize files in a filesystem (harddisk).
the thing that I was complaining so loudly is that pd-extended ships all these libraries but does not add the paths.
Yes, that's exactly what I mean: Many people would like every objectclass to be global.
but that is not a problem for pd-extended users (and I want to solve the pd-extended problems here), as long as you can overrule the global namespace with a local namespace.
Not really: Say I use [urn] in Pd-extended. Which [urn] am I using?
As pd-extended by popular demand (and for practical reasons) is configured to allow access to one of the [urn]s out of the box, I believe not many people are actually using the names [zexy/urn] or [maxlib/urn] or [cyclone/urn]. But all of these behave differently. So we have a hidden nameclash if you try to use a patch that assumes [urn] to be the one from the library, pd-extended loads as the
second one. Now IIRC Hans' goal is to not load any library or set any path out of the box, so that all names would have to be qualified with directory prefixes or [declare]d. But when this behavious
accidentally came into effect because of the change in plist-location on OS-X, people complained about missing objects and that their patches were broken with the new pd-extended. Note that I don't want to rate if they complained for a good reason, I just want to point to a
problem.pd-extended would provide a default object for every nameclash. If you have old patches that were using objects, that are not the default in pd-extended you would have to add a declare to your patch. or explicitely call them as mynondefaultlib/abs~.
So you see: pd-extended selected a certain set of externals to be
the default set of available objectclasses in pd-extended. I don't know how it was decided which libs should be these defaults, I don't even know which ones are the defaults. Probably Hans just chose some popular ones, which is a sensible thing to do.In the long run, this process should become a bit more organized and it especially should not be handled along library/author
borders. For example, I think, zexy (rightfully) has a high loading priority, because it's one of the oldest and most widely used library. But Cyclone also deserves a high priority because it's generally Max-compatible. OTOH zexy is older. What to do? If we only priorize complete libraries, we're not able to make finely grained decisions about single objects. Maybe zexy's [abs~] is better, while [urn] in Cyclone is preferable.In the end we may be back at square one: a "flatspace" with the selected best of the (un)pack objectclasses in a single
directory. No problems with path settings, all is fine again.Or what am I missing? ;)
The flatspace model breaks down when you start adding libraries
to Pd- extended. Then you can have nameclashes again. Say someone writes their own library with an [urn], then what happens? At best, confusion ensues.If we look at other programming languages, we can see that
namespaces are a very common solution to this problem (C++, Tcl, python, Java, Smalltalk, etc). I see no reason why it wouldn't work for Pd as
well..hc
There is no way to peace, peace is the way. -A.J. Muste
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
Hans-Christoph Steiner wrote:
- I think it should be possible to do [import list-abs/list-split]
but I haven't looked at it too much yet.
this feature is afaik broken, because if you do [import list-abs/list-split] then pd does not find [list-abs/list-split anymore (only [list=split]. marius.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Apr 16, 2008, at 2:58 PM, Frank Barknecht wrote:
In the end we may be back at square one: a "flatspace" with the selected best of the (un)pack objectclasses in a single directory. No problems with path settings, all is fine again.
Or what am I missing? ;)
The flatspace model breaks down when you start adding libraries to Pd- extended. Then you can have nameclashes again. Say someone writes
their own library with an [urn], then what happens? At best,
confusion ensues.
I should have written "best of the (un)pack objectclasses in a single *namespace*", not a directory. But that's how pd-extended is setup and used in practice ATM.
If we look at other programming languages, we can see that namespaces
are a very common solution to this problem (C++, Tcl, python, Java,
Smalltalk, etc). I see no reason why it wouldn't work for Pd as well.
Me neither. I just see a discrepancy between theory and real life and am searching for the reason. ;)
Ciao
Frank Barknecht
On Apr 17, 2008, at 2:31 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Apr 16, 2008, at 2:58 PM, Frank Barknecht wrote:
In the end we may be back at square one: a "flatspace" with the selected best of the (un)pack objectclasses in a single
directory. No problems with path settings, all is fine again.Or what am I missing? ;)
The flatspace model breaks down when you start adding libraries to
Pd- extended. Then you can have nameclashes again. Say someone writes their own library with an [urn], then what happens? At best, confusion ensues.I should have written "best of the (un)pack objectclasses in a single *namespace*", not a directory. But that's how pd-extended is setup and used in practice ATM.
If we look at other programming languages, we can see that namespaces are a very common solution to this problem (C++, Tcl, python, Java, Smalltalk, etc). I see no reason why it wouldn't work for Pd as
well.Me neither. I just see a discrepancy between theory and real life
and am searching for the reason. ;)
This is the reason AFAIK: The namespace stuff isn't fully
implemented, plus people are used to working in a single namespace,
so first things need to be fixed, then we need to work out a
transistion plan.
.hc
Ciao
Frank Barknecht
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
I would love to have everything well documented, but alas,
documentation takes a long time. So I think the best way to spend
time is to first get the code working well, then document it.
Otherwise, you have to change the code AND the documentation to fix it.
There is lots of discussion in the list archives on these topics.
Personally, I have written a lot of documentation while I was
figuring out some code. I think that works well, and I encourage
others to try to do that.
.hc
On Apr 15, 2008, at 3:26 PM, marius schebella wrote:
Hans-Christoph Steiner wrote:
Lots of people contribute, but I am the person who manages the
releases. Any help is welcome. The path/import/declare stuff is
currently a half-complete effort of Miller's and mine.is there a page where this idea is documented? how is it supposed
to work in the future? I still don't know. will I have to include
declare in every patch that I write???Basically up until recently, I was pursing Pd-extended as a proof
of concept for building libraries as standalone binaries in
directories instead of all compiled into one binary. I think that
clearly works, so now it is time to clean things up into a
coherent package.It doesn't work for abbreviations.
I document what I can here: http://puredata.info/docs/developer/
thanks.
I don't really know what else needs to be documented. One way to
find out is when people start to contribute, then they find
shortcomings that we can fill in.well, it would be nice if there was some documentation of which
libraries and objects are included, how to handle all the path
problems, which paths and libs are loaded by default how to load
the other libs/externals. filessystem layout, platform
compatibility, which libraries do *not* work on which os. what
additional features you added to pd-extended (advanced helpmenu,
advanced tcltk interface (colorscheme...), differences in
shortcuts, closing, ..... all that.marius.
.hc On Apr 15, 2008, at 2:15 PM, marius schebella wrote:
Hi, is it true, that only hans is working on the pd-extended
releases? are there other maintainers? I got the impression in the past that pd-extended is very useful
(and I personally use it a lot), but development for it is also very
cryptical and almost hidden like a secret. and often things are implemented
that seem to be good ideas, but do not really work (like the whole path/import stuff). maybe hans, if you could provide more information and documentation about pd-extended and how the whole integration of libraries
works then more people would be able to help you and development would be more consistent. what is the direction that you want to go? for me pd-extended is the attempt to create a pd distribution that includes as many as possible external libraries in addition to pd vanilla. I love most of the things in pd-ext, although there is
still a lot of work that needs to be done... marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
------- I have the audacity to believe that peoples everywhere can
have three meals a day for their bodies, education and culture for
their minds, and dignity, equality and freedom for their
spirits. - Martin Luther King, Jr.
All information should be free. - the hacker ethic
-
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Luke Iannini (pd) -
marius schebella -
Roman Haefeli