Hey Cyrille,
I just noticed that you added pbank.c to the flatspace library. That whole 'flatspace' thing is kludge, and should be deprecated, IMHO and just left alone. So I think that it would be best to remove externals/ build/src/pbank.c.
For new externals, I think they should first be distributed outside of Pd-extended until they are stable, then things they can be included as libraries.
Also, the helpfile is named wrong, it should be pbank-help.pd, not help-pbank.pd.
.hc
----------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
Hans-Christoph Steiner a écrit :
Hey Cyrille,
I just noticed that you added pbank.c to the flatspace library. That whole 'flatspace' thing is kludge,
i know, but there is no better solution yet.
and should be deprecated, IMHO and just left alone. So I think that it would be best to remove externals/ build/src/pbank.c.
where would it go?
For new externals, I think they should first be distributed outside of Pd-extended until they are stable,
pbank is stable. it was distributed by zack settle in the jimmies for years, and i use it since 2002 or 2003.
then things they can be included as libraries.
what lib?
when pd-extended or the cvs will be ordered to have directory like : /math /audio/math /audio/effect /save /matrix
etc, then pbank and other externals would fit there. but now it's just an ugly mess. i don't think pbank add much to this mess.
i personally think it's time to start an other svn for pd-extendedV2, create a good structure, and copy code from 1st svn to the 2nd, without ordering by developer, but by functionality. that's the best way to move i see, but of course that will create endless flame-war on the list.
Also, the helpfile is named wrong, it should be pbank-help.pd, not help-pbank.pd.
ok, i changed it.
cyrille
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Feb 23, 2009, at 6:05 AM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
Hey Cyrille, I just noticed that you added pbank.c to the flatspace library. That whole 'flatspace' thing is kludge,
i know, but there is no better solution yet.
and should be deprecated, IMHO and just left alone. So I think that it would be best to remove externals/ build/src/pbank.c.
where would it go?
For new externals, I think they should first be distributed outside of Pd-extended until they are stable,
pbank is stable. it was distributed by zack settle in the jimmies for years, and i use it since 2002 or 2003.
then things they can be included as libraries.
what lib?
when pd-extended or the cvs will be ordered to have directory like : /math /audio/math /audio/effect /save /matrix
etc, then pbank and other externals would fit there. but now it's just an ugly mess. i don't think pbank add much to this mess.
i personally think it's time to start an other svn for pd- extendedV2, create a good structure, and copy code from 1st svn to the 2nd, without ordering by developer, but by functionality. that's the best way to move i see, but of course that will create endless flame-war on the list.
I agree here, and that is the direction I am working towards with any Pd code I work on. But for pbank, how about just compiling it and releasing it on its own?
Or there is already a 'nusmuk' library in Pd-extended, with only abstractions. How about moving abstractions/nusmuk to externals/ nusmuk, then including pbank in there?
.hc
Also, the helpfile is named wrong, it should be pbank-help.pd, not help-pbank.pd.
ok, i changed it.
cyrille
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Hans-Christoph Steiner a écrit :
On Feb 23, 2009, at 6:05 AM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
Hey Cyrille, I just noticed that you added pbank.c to the flatspace library. That whole 'flatspace' thing is kludge,
i know, but there is no better solution yet.
and should be deprecated, IMHO and just left alone. So I think that it would be best to remove externals/ build/src/pbank.c.
where would it go?
For new externals, I think they should first be distributed outside of Pd-extended until they are stable,
pbank is stable. it was distributed by zack settle in the jimmies for years, and i use it since 2002 or 2003.
then things they can be included as libraries.
what lib?
when pd-extended or the cvs will be ordered to have directory like : /math /audio/math /audio/effect /save /matrix
etc, then pbank and other externals would fit there. but now it's just an ugly mess. i don't think pbank add much to this mess.
i personally think it's time to start an other svn for pd- extendedV2, create a good structure, and copy code from 1st svn to the 2nd, without ordering by developer, but by functionality. that's the best way to move i see, but of course that will create endless flame-war on the list.
I agree here, and that is the direction I am working towards with any Pd code I work on. But for pbank, how about just compiling it and releasing it on its own?
Or there is already a 'nusmuk' library in Pd-extended, with only abstractions. How about moving abstractions/nusmuk to externals/ nusmuk, then including pbank in there?
yep, that's an option. but i would prefer to organise this properly (i.e. not by developer but by functionality)
for now, using flatspace is the only way i know to include code in pd-extended, i'll digg more when i'll get time.
cyrille
.hc
Also, the helpfile is named wrong, it should be pbank-help.pd, not help-pbank.pd.
ok, i changed it.
cyrille
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
when pd-extended or the cvs will be ordered to have directory like : /math /audio/math /audio/effect /save /matrix
but i would prefer to organise this properly (i.e. not by developer but by functionality)
for now, using flatspace is the only way i know to include code in pd-extended, i'll digg more when i'll get time.
is something like this possible: each developer drops his stuff in svn in the current structure, but when compiled all externals are divided into categories (e.g. like the above named)? each developer has his own corner to drop stuff, but he has to check to which category each object belongs to, and they get distributed at compiling time. and, unchecked objects don't get compiled.
is this feasible/logic? it sounds logic to me, as f.e. my abstractions cover a bit of everything: GUI, midi, audio, ...
Also, the amount of categories should be discussed, and probably on the main list. I think that MP's original list isn't enough, and new categories should be included (especially considering the amount and diversity of objects in pd-ext). audio filters, generators, effects, ... I can look at the pd-ext-list I've made and give a concrete suggestion in the next days, if you want. this discussion will be a bit chaotic, but it should go to the main list/pdpedia.
João Pais a écrit :
when pd-extended or the cvs will be ordered to have directory like : /math /audio/math /audio/effect /save /matrix
but i would prefer to organise this properly (i.e. not by developer but by functionality)
for now, using flatspace is the only way i know to include code in pd-extended, i'll digg more when i'll get time.
is something like this possible: each developer drops his stuff in svn in the current structure, but when compiled all externals are divided into categories (e.g. like the above named)? each developer has his own corner to drop stuff, but he has to check to which category each object belongs to, and they get distributed at compiling time. and, unchecked objects don't get compiled.
is this feasible/logic? it sounds logic to me, as f.e. my abstractions cover a bit of everything: GUI, midi, audio, ...
Also, the amount of categories should be discussed, and probably on the main list. I think that MP's original list isn't enough, and new categories should be included (especially considering the amount and diversity of objects in pd-ext). audio filters, generators, effects, ... I can look at the pd-ext-list I've made and give a concrete suggestion in the next days, if you want. this discussion will be a bit chaotic, but it should go to the main list/pdpedia.
yes,i think such proposition can be constructive.
On Feb 25, 2009, at 5:07 AM, cyrille henry wrote:
João Pais a écrit :
when pd-extended or the cvs will be ordered to have directory like : /math /audio/math /audio/effect /save /matrix
but i would prefer to organise this properly (i.e. not by developer but by functionality)
for now, using flatspace is the only way i know to include code in pd-extended, i'll digg more when i'll get time.
is something like this possible: each developer drops his stuff in svn in the current structure, but when compiled all externals are divided into categories (e.g. like the above named)? each developer has his own corner to drop stuff, but he has to check to which category each object belongs to, and they get distributed at compiling time. and, unchecked objects don't get compiled. is this feasible/logic? it sounds logic to me, as f.e. my abstractions cover a bit of everything: GUI, midi, audio, ... Also, the amount of categories should be discussed, and probably on the main list. I think that MP's original list isn't enough, and new categories should be included (especially considering the amount and diversity of objects in pd-ext). audio filters, generators, effects, ... I can look at the pd-ext-list I've made and give a concrete suggestion in the next days, if you want. this discussion will be a bit chaotic, but it should go to the main list/pdpedia.
yes,i think such proposition can be constructive.
Honestly, I think the libraries should not be automatically formed. They should be owned by someone and designed as a whole, not pieced together from random bits. This is how libraries are usually written in Perl, Python, etc. etc. This would ensure that the objectclasses in a library have matching interfaces, and work well together.
.hc
----------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic
On Wed, Feb 25, 2009 at 7:33 AM, Hans-Christoph Steiner hans@eds.org wrote:
On Feb 25, 2009, at 5:07 AM, cyrille henry wrote:
João Pais a écrit :
when pd-extended or the cvs will be ordered to have directory like : /math /audio/math /audio/effect /save /matrix
but i would prefer to organise this properly (i.e. not by developer but by functionality)
for now, using flatspace is the only way i know to include code in pd-extended, i'll digg more when i'll get time.
is something like this possible: each developer drops his stuff in svn in the current structure, but when compiled all externals are divided into categories (e.g. like the above named)? each developer has his own corner to drop stuff, but he has to check to which category each object belongs to, and they get distributed at compiling time. and, unchecked objects don't get compiled. is this feasible/logic? it sounds logic to me, as f.e. my abstractions cover a bit of everything: GUI, midi, audio, ... Also, the amount of categories should be discussed, and probably on the main list. I think that MP's original list isn't enough, and new categories should be included (especially considering the amount and diversity of objects in pd-ext). audio filters, generators, effects, ... I can look at the pd-ext-list I've made and give a concrete suggestion in the next days, if you want. this discussion will be a bit chaotic, but it should go to the main list/pdpedia.
yes,i think such proposition can be constructive.
Honestly, I think the libraries should not be automatically formed. They should be owned by someone and designed as a whole, not pieced together from random bits. This is how libraries are usually written in Perl, Python, etc. etc. This would ensure that the objectclasses in a library have matching interfaces, and work well together.
My suggestion is certainly aimed towards that goal, but tackled with an iterative approach.
Basically, organization of the libs could not really be any /worse/ than it is now (e.g. I'm constantly checking ggee, hcs, moonlib and zexy to find various OS and filesystem externals I need), so I'm basically proposing the same thing you are, but approached as follows: * Lazy consensus on a directory structure (I think we were already making very nice progress on that in the "Proposals for object categories" thread before it went off track : ) ) * Creation of a branch of SVN with the directory structure in place * Everyone works together to shuffle the many libs into the new structure * We each claim a domain we'd like to maintain * And then, finally, the maintainer (with help from consenting developers where necessary) begin to rewrite the objects in that category to have a consistent interface.
One of the benefits of this is it will become much clearer what that common interface should be once many objects of the same type are collected together. And I think it will be much more likely for maintainers to step forward once the libraries are loosely assembled, since the potential will be so much clearer.
And of course this does not need to be a mandate - if a developer would rather keep all his/her stuff together, that's fine. And, there will always be exceptions like rtc-lib or sigpack that shouldn't really be split up.
But, on the other side, I'm assuming there are many developers that would be more than happy to move their code into common categories - at the very least including myself, João and Cyrille, and only haven't done so because the structure did not exist. And personally I'd be just as willing to adapt the interfaces of my abstractions to a category-defined standard, but once again, none exists now to adapt to.
Does that make sense? Best Luke
.hc
Mistrust authority - promote decentralization. - the hacker ethic
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Basically, organization of the libs could not really be any /worse/ than it is now (e.g. I'm constantly checking ggee, hcs, moonlib and zexy to find various OS and filesystem externals I need), so I'm basically proposing the same thing you are, but approached as follows:
- Lazy consensus on a directory structure (I think we were already
making very nice progress on that in the "Proposals for object categories" thread before it went off track : ) )
I can start organising the info in a wiki page later in the day. I guess this is point where we all agreed, we should try to move in the direction of a structured pd-ext?
- Creation of a branch of SVN with the directory structure in place
- Everyone works together to shuffle the many libs into the new structure
- We each claim a domain we'd like to maintain
- And then, finally, the maintainer (with help from consenting
developers where necessary) begin to rewrite the objects in that category to have a consistent interface.
is the consistent interface really necessary? there was already some discussion about the layout for the pddp project (am I right?), maybe elements from there could be taken? or maybe it's enough to provide a general template with guidelines to be followed, in case the developer wants the objects to become part of pd-ext? f.e., I have a consistent approach to the documentation of my abstractions - of course I can use another graphical template, but that might open lots of unecessary discussions: "why these colors", "why this layout", "why so many graphics and not only text", .....
But I think that in general it should be stressed that objects should be stable and properly documented.
And of course this does not need to be a mandate - if a developer would rather keep all his/her stuff together, that's fine. And, there will always be exceptions like rtc-lib or sigpack that shouldn't really be split up.
shouldn't they really? depends on what you're talking about - rtc, vasp, etc. are very cohese libs, that anyway don't go much outside their domains - their developers even made that separation clear, by putting other externals available elsewhere. they could easily go to /control/rtc or /control/array/vasp or etc. But for not so tight lib-packages, is it that bad to separate objects, as long as they're all available on path?
But, on the other side, I'm assuming there are many developers that would be more than happy to move their code into common categories - at the very least including myself, João and Cyrille, and only haven't done so because the structure did not exist. And personally I'd be just as willing to adapt the interfaces of my abstractions to a category-defined standard, but once again, none exists now to adapt to.
I have no problem in structuring my abstractions (I can't code), but my "lib" is probably one of the most simple ones.
On Feb 26, 2009, at 11:22 AM, João Pais wrote:
Basically, organization of the libs could not really be any /worse/ than it is now (e.g. I'm constantly checking ggee, hcs, moonlib and zexy to find various OS and filesystem externals I need), so I'm basically proposing the same thing you are, but approached as follows:
- Lazy consensus on a directory structure (I think we were already
making very nice progress on that in the "Proposals for object categories" thread before it went off track : ) )
I can start organising the info in a wiki page later in the day. I guess this is point where we all agreed, we should try to move in the direction of a structured pd-ext?
I see what you mean now, so like a "standard lib" or JDK for Pd. Sounds like a good idea. I think it makes sense to start organizing this stuff now, but I am guessing it will have to be finalized at the PdCon in Sao Paulo. This kind of thing is vastly easier to do it person than via email. I am sure was can also do audio/video chat and even streaming and IRC for this meeting to include people that are not there.
There is already a wiki page with some info that you can build upon:
http://puredata.info/dev/PdLibraries
.hc
- Creation of a branch of SVN with the directory structure in place
- Everyone works together to shuffle the many libs into the new
structure
- We each claim a domain we'd like to maintain
- And then, finally, the maintainer (with help from consenting
developers where necessary) begin to rewrite the objects in that category to have a consistent interface.
is the consistent interface really necessary? there was already some discussion about the layout for the pddp project (am I right?), maybe elements from there could be taken? or maybe it's enough to provide a general template with guidelines to be followed, in case the developer wants the objects to become part of pd-ext? f.e., I have a consistent approach to the documentation of my abstractions - of course I can use another graphical template, but that might open lots of unecessary discussions: "why these colors", "why this layout", "why so many graphics and not only text", .....
But I think that in general it should be stressed that objects should be stable and properly documented.
And of course this does not need to be a mandate - if a developer would rather keep all his/her stuff together, that's fine. And, there will always be exceptions like rtc-lib or sigpack that shouldn't really be split up.
shouldn't they really? depends on what you're talking about - rtc, vasp, etc. are very cohese libs, that anyway don't go much outside their domains - their developers even made that separation clear, by putting other externals available elsewhere. they could easily go to /control/rtc or /control/array/vasp or etc. But for not so tight lib-packages, is it that bad to separate objects, as long as they're all available on path?
But, on the other side, I'm assuming there are many developers that would be more than happy to move their code into common categories - at the very least including myself, João and Cyrille, and only haven't done so because the structure did not exist. And personally I'd be just as willing to adapt the interfaces of my abstractions to a category-defined standard, but once again, none exists now to adapt to.
I have no problem in structuring my abstractions (I can't code), but my "lib" is probably one of the most simple ones.
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
On Feb 24, 2009, at 11:57 AM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
On Feb 23, 2009, at 6:05 AM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
Hey Cyrille, I just noticed that you added pbank.c to the flatspace library. That whole 'flatspace' thing is kludge,
i know, but there is no better solution yet.
and should be deprecated, IMHO and just left alone. So I think that it would be best to remove externals/ build/src/pbank.c.
where would it go?
For new externals, I think they should first be distributed outside of Pd-extended until they are stable,
pbank is stable. it was distributed by zack settle in the jimmies for years, and i use it since 2002 or 2003.
then things they can be included as libraries.
what lib?
when pd-extended or the cvs will be ordered to have directory like : /math /audio/math /audio/effect /save /matrix
etc, then pbank and other externals would fit there. but now it's just an ugly mess. i don't think pbank add much to this mess.
i personally think it's time to start an other svn for pd- extendedV2, create a good structure, and copy code from 1st svn to the 2nd, without ordering by developer, but by functionality. that's the best way to move i see, but of course that will create endless flame-war on the list.
I agree here, and that is the direction I am working towards with any Pd code I work on. But for pbank, how about just compiling it and releasing it on its own? Or there is already a 'nusmuk' library in Pd-extended, with only abstractions. How about moving abstractions/nusmuk to externals/ nusmuk, then including pbank in there?
yep, that's an option. but i would prefer to organise this properly (i.e. not by developer but by functionality)
Me too! Start a library for pbank to fit in then! :D
for now, using flatspace is the only way i know to include code in pd-extended, i'll digg more when i'll get time.
For future reference, please everyone leave flatspace as it is. It is deprecated and only there for backwards compatibility.
.hc
cyrille
.hc
Also, the helpfile is named wrong, it should be pbank-help.pd, not help-pbank.pd.
ok, i changed it.
cyrille
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!
-
cyrille henry -
Hans-Christoph Steiner -
João Pais -
Luke Iannini