On Tue, Feb 24, 2009 at 4:34 PM, João Pais jmmmpais@googlemail.com wrote:
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.
Yo, Perhaps an interesting way to approach this would be for each developer to hierarchize their own collection, and then we can find the common ground between them all. It also might be nice for everyone to claim a library and stand as its maintainer, as Frank has done for list-abs/ and Cyrille and HC have done for mapping/, etc. I've begun ds-gui/ to this effect...
Best Luke
And, here's an example from my own sfruit/ collection: gui/ (for extending, interacting with, or working around limitations of the IEMGUIs) ds-gui/ ds-abs/ keyboard/ hid/ color/ control/ (i'm guessing everyone has enough of these that we'll have to make this finer-grained) dialog/ (these are different manifestations of "dialog boxes" in Pd) gem/ OSC/ list-abs-extended/ (these are list-abs that require objects not in Pd-vanilla (a restriction laid down by Frank long ago for list-abs)) midi/ sequencing/ signal/ envelope/ mix/ oscillators/ os/
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
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, ...
(The following uses the term "library" also for abstraction collections.)
There is one big problem to solve with reorganizing (which I'm generally in favour of): interdependencies between libraries.
That's why [list]-abs deliberately avoids these completely and relies only on Pd-vanilla, but libs like RTClib or mapping etc. depend on other collections (RTClib depends on [list]-abs and some externals, mapping has purepd and externals,...)
Now if you rename all libraries you will also have to change some of their objects to refer to the objects in new ways. mapping for example could not use [purepd/float_argument] anymore and would have to be changed to something like [utils/float_argument] or [import utils]+[float_argument]. But then, mapping would not work in other distributions anymore.
A route that I would suggest (and suggested several times in the past) would be to work on a kind of standard library that
a) consists only of abstractions b) uses no externals at all c) is selfcontained (i.e. no interdependencies)
If you feel reminded of [list]-abs now, that's intentional. Basically such a standard library would define an *interface* for standard objects. Where performance is an issue, the interface could alternatively implemented with externals. This also is exemplified in [list]-abs, where personally I use a version of [list-drip] that has zexy's [drip] inside for speed reasons. It behaves exactly like the abstraction version so it doesn't matter if people don't have zexy installed.
Actually I'm working on such a project for a while now: the rj-lib for RjDj http://trac.rjdj.me/wiki/RjLibnew It's pure vanilla, has a well documented and (generally) consistend interface, has categories, a preset system and is generally patched in a clean, KISS and self-contained way. It's not so much intended to be "loaded" with -path, instead you should just drop the "rj" directory into your project directory as a whole and use the objects either as [rj/s_drumelectro] or you use [declare -patch rj] in your main patch and write the object names as [s_drumelectro]. This works surprisingly well: Most of the Scenes written for RjDj use this library sucessfully, although it's still far from 1.0.
Ciao
Frank Barknecht a écrit : ...
There is one big problem to solve with reorganizing (which I'm generally in favour of): interdependencies between libraries.
That's why [list]-abs deliberately avoids these completely and relies only on Pd-vanilla, but libs like RTClib or mapping etc. depend on other collections (RTClib depends on [list]-abs and some externals, mapping has purepd and externals,...)
Now if you rename all libraries you will also have to change some of their objects to refer to the objects in new ways. mapping for example could not use [purepd/float_argument] anymore and would have to be changed to something like [utils/float_argument] or [import utils]+[float_argument]. But then, mapping would not work in other distributions anymore.
that's why my proposition was to start a new svn, using the 1st while organising the 2nd. then deprecated the 1st....
A route that I would suggest (and suggested several times in the past) would be to work on a kind of standard library that
a) consists only of abstractions b) uses no externals at all c) is selfcontained (i.e. no interdependencies)
this is very nice, but sometime not possible. i really like the physical model mapping, so i need msd for some mapping externals...
but yes, somthing like float_argument should be forked to go in the mapping directory.
cyrille
If you feel reminded of [list]-abs now, that's intentional. Basically such a standard library would define an *interface* for standard objects. Where performance is an issue, the interface could alternatively implemented with externals. This also is exemplified in [list]-abs, where personally I use a version of [list-drip] that has zexy's [drip] inside for speed reasons. It behaves exactly like the abstraction version so it doesn't matter if people don't have zexy installed.
Actually I'm working on such a project for a while now: the rj-lib for RjDj http://trac.rjdj.me/wiki/RjLibnew It's pure vanilla, has a well documented and (generally) consistend interface, has categories, a preset system and is generally patched in a clean, KISS and self-contained way. It's not so much intended to be "loaded" with -path, instead you should just drop the "rj" directory into your project directory as a whole and use the objects either as [rj/s_drumelectro] or you use [declare -patch rj] in your main patch and write the object names as [s_drumelectro]. This works surprisingly well: Most of the Scenes written for RjDj use this library sucessfully, although it's still far from 1.0.
Ciao
On Feb 25, 2009, at 4:03 AM, Frank Barknecht wrote:
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
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, ...
(The following uses the term "library" also for abstraction collections.)
There is one big problem to solve with reorganizing (which I'm generally in favour of): interdependencies between libraries.
That's why [list]-abs deliberately avoids these completely and relies only on Pd-vanilla, but libs like RTClib or mapping etc. depend on other collections (RTClib depends on [list]-abs and some externals, mapping has purepd and externals,...)
Now if you rename all libraries you will also have to change some of their objects to refer to the objects in new ways. mapping for example could not use [purepd/float_argument] anymore and would have to be changed to something like [utils/float_argument] or [import utils]+[float_argument]. But then, mapping would not work in other distributions anymore.
I think it would be a bad idea to just rename libraries. Instead of these top-down views of categories of libraries, I suggest that people just start making topic-organized libraries in topics that they are interested in. That's how it was done with 'mapping' and 'apple'.
As for old dependencies, we can keep the 'purepd' library in there until nothing depends on it. Its just files in the file system if they are not used, so I don't see the harm.
A route that I would suggest (and suggested several times in the past) would be to work on a kind of standard library that
a) consists only of abstractions b) uses no externals at all c) is selfcontained (i.e. no interdependencies)
If you feel reminded of [list]-abs now, that's intentional. Basically such a standard library would define an *interface* for standard objects. Where performance is an issue, the interface could alternatively implemented with externals. This also is exemplified in [list]-abs, where personally I use a version of [list-drip] that has zexy's [drip] inside for speed reasons. It behaves exactly like the abstraction version so it doesn't matter if people don't have zexy installed.
Actually I'm working on such a project for a while now: the rj-lib for RjDj http://trac.rjdj.me/wiki/RjLibnew It's pure vanilla, has a well documented and (generally) consistend interface, has categories, a preset system and is generally patched in a clean, KISS and self-contained way. It's not so much intended to be "loaded" with -path, instead you should just drop the "rj" directory into your project directory as a whole and use the objects either as [rj/s_drumelectro] or you use [declare -patch rj] in your main patch and write the object names as [s_drumelectro]. This works surprisingly well: Most of the Scenes written for RjDj use this library sucessfully, although it's still far from 1.0.
I think you outlined the argument against this proposal with your zexy example. It doesn't sound like a real solution if you include one version of list-drip in the list-abs library because of technical restrictions, but then you use a different version because it works better. Why not have a system of libraries where you can use the code that works better?
That is why it is important to have a library format and search path behavior that treats all objectclasses as equals, whether they are written in Pd, C, Lua, etc.
.hc
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
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 a écrit :
On Feb 25, 2009, at 4:03 AM, Frank Barknecht wrote:
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
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, ...
(The following uses the term "library" also for abstraction collections.)
There is one big problem to solve with reorganizing (which I'm generally in favour of): interdependencies between libraries.
That's why [list]-abs deliberately avoids these completely and relies only on Pd-vanilla, but libs like RTClib or mapping etc. depend on other collections (RTClib depends on [list]-abs and some externals, mapping has purepd and externals,...)
Now if you rename all libraries you will also have to change some of their objects to refer to the objects in new ways. mapping for example could not use [purepd/float_argument] anymore and would have to be changed to something like [utils/float_argument] or [import utils]+[float_argument]. But then, mapping would not work in other distributions anymore.
I think it would be a bad idea to just rename libraries. Instead of these top-down views of categories of libraries, I suggest that people just start making topic-organized libraries in topics that they are interested in. That's how it was done with 'mapping' and 'apple'.
As for old dependencies, we can keep the 'purepd' library in there until nothing depends on it. Its just files in the file system if they are not used, so I don't see the harm.
yep. so how should i remove purepd dependency of the mapping lib :
-should i copy purepd/once to mapping/once and change in the purepd/once object to once
-should i copy purepd/once to mapping/mapping_once and change in the purepd/once object to mapping_once
?
A route that I would suggest (and suggested several times in the past) would be to work on a kind of standard library that
a) consists only of abstractions b) uses no externals at all c) is selfcontained (i.e. no interdependencies)
If you feel reminded of [list]-abs now, that's intentional. Basically such a standard library would define an *interface* for standard objects. Where performance is an issue, the interface could alternatively implemented with externals. This also is exemplified in [list]-abs, where personally I use a version of [list-drip] that has zexy's [drip] inside for speed reasons. It behaves exactly like the abstraction version so it doesn't matter if people don't have zexy installed.
Actually I'm working on such a project for a while now: the rj-lib for RjDj http://trac.rjdj.me/wiki/RjLibnew It's pure vanilla, has a well documented and (generally) consistend interface, has categories, a preset system and is generally patched in a clean, KISS and self-contained way. It's not so much intended to be "loaded" with -path, instead you should just drop the "rj" directory into your project directory as a whole and use the objects either as [rj/s_drumelectro] or you use [declare -patch rj] in your main patch and write the object names as [s_drumelectro]. This works surprisingly well: Most of the Scenes written for RjDj use this library sucessfully, although it's still far from 1.0.
I think you outlined the argument against this proposal with your zexy example. It doesn't sound like a real solution if you include one version of list-drip in the list-abs library because of technical restrictions, but then you use a different version because it works better. Why not have a system of libraries where you can use the code that works better?
because zexy is not available for iphone. so both list_drip are important.
That is why it is important to have a library format and search path behavior that treats all objectclasses as equals, whether they are written in Pd, C, Lua, etc.
i think we can have a list-abstraction library and a list-abstration-optimised and a list-abstraction-optimised-mmx
the 1st contain all list-abs in pd vanilla, the 2nd could contain objects using zexy the 3d contain binary compiled with mmx optimisation. the object in the 3d could override the object in the 2nd (and 2d override the 1st).
so everybody is happy : you can always use a vanilla abstraction, or a more optimized on, if your computer allow it.
cyrille
.hc
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Feb 25, 2009, at 1:51 PM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
On Feb 25, 2009, at 4:03 AM, Frank Barknecht wrote:
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
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, ...
(The following uses the term "library" also for abstraction collections.)
There is one big problem to solve with reorganizing (which I'm generally in favour of): interdependencies between libraries.
That's why [list]-abs deliberately avoids these completely and relies only on Pd-vanilla, but libs like RTClib or mapping etc. depend on other collections (RTClib depends on [list]-abs and some externals, mapping has purepd and externals,...)
Now if you rename all libraries you will also have to change some of their objects to refer to the objects in new ways. mapping for example could not use [purepd/float_argument] anymore and would have to be changed to something like [utils/float_argument] or [import utils]+[float_argument]. But then, mapping would not work in other distributions anymore.
I think it would be a bad idea to just rename libraries. Instead of these top-down views of categories of libraries, I suggest that people just start making topic-organized libraries in topics that they are interested in. That's how it was done with 'mapping' and 'apple'. As for old dependencies, we can keep the 'purepd' library in there until nothing depends on it. Its just files in the file system if they are not used, so I don't see the harm.
yep. so how should i remove purepd dependency of the mapping lib :
-should i copy purepd/once to mapping/once and change in the purepd/ once object to once
-should i copy purepd/once to mapping/mapping_once and change in the purepd/once object to mapping_once
'purepd' is pure Pd, so just copy the folder where you need it. That will work on any Pd distro. Maintaining many different copies of the same object is not a solution.
For example, if you put the purepd folder in your project, then [purepd/once] will work.
.hc
?
A route that I would suggest (and suggested several times in the past) would be to work on a kind of standard library that
a) consists only of abstractions b) uses no externals at all c) is selfcontained (i.e. no interdependencies)
If you feel reminded of [list]-abs now, that's intentional. Basically such a standard library would define an *interface* for standard objects. Where performance is an issue, the interface could alternatively implemented with externals. This also is exemplified in [list]-abs, where personally I use a version of [list-drip] that has zexy's [drip] inside for speed reasons. It behaves exactly like the abstraction version so it doesn't matter if people don't have zexy installed.
Actually I'm working on such a project for a while now: the rj-lib for RjDj http://trac.rjdj.me/wiki/RjLibnew It's pure vanilla, has a well documented and (generally) consistend interface, has categories, a preset system and is generally patched in a clean, KISS and self-contained way. It's not so much intended to be "loaded" with -path, instead you should just drop the "rj" directory into your project directory as a whole and use the objects either as [rj/s_drumelectro] or you use [declare -patch rj] in your main patch and write the object names as [s_drumelectro]. This works surprisingly well: Most of the Scenes written for RjDj use this library sucessfully, although it's still far from 1.0.
I think you outlined the argument against this proposal with your zexy example. It doesn't sound like a real solution if you include one version of list-drip in the list-abs library because of technical restrictions, but then you use a different version because it works better. Why not have a system of libraries where you can use the code that works better?
because zexy is not available for iphone. so both list_drip are important.
That is why it is important to have a library format and search path behavior that treats all objectclasses as equals, whether they are written in Pd, C, Lua, etc.
i think we can have a list-abstraction library and a list-abstration- optimised and a list-abstraction-optimised-mmx
the 1st contain all list-abs in pd vanilla, the 2nd could contain objects using zexy the 3d contain binary compiled with mmx optimisation. the object in the 3d could override the object in the 2nd (and 2d override the 1st).
so everybody is happy : you can always use a vanilla abstraction, or a more optimized on, if your computer allow it.
cyrille
.hc
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think you outlined the argument against this proposal with your zexy example. It doesn't sound like a real solution if you include one version of list-drip in the list-abs library because of technical restrictions, but then you use a different version because it works better.
Both [list-drip] objects from a user perspective work exactly the same, only that one is faster. If you encounter a patch that uses [list-drip] it's much better to have a slow [list-drip] than no [list-drip] at all.
On some platforms not every external etc. is available. E.g. zexy is not available in RjDj's Pd or in a plain vanilla install so you cannot use [drip]. [list-drip] however can just be dropped into your working directory and you can use it.
Abstractions and Pd builtins work everywhere, so they are the common denominator.
Ciao
On Feb 25, 2009, at 2:12 PM, Frank Barknecht wrote:
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think you outlined the argument against this proposal with your zexy example. It doesn't sound like a real solution if you include one version of list-drip in the list-abs library because of technical restrictions, but then you use a different version because it works better.
Both [list-drip] objects from a user perspective work exactly the same, only that one is faster. If you encounter a patch that uses [list-drip] it's much better to have a slow [list-drip] than no [list-drip] at all.
On some platforms not every external etc. is available. E.g. zexy is not available in RjDj's Pd or in a plain vanilla install so you cannot use [drip]. [list-drip] however can just be dropped into your working directory and you can use it.
Abstractions and Pd builtins work everywhere, so they are the common denominator.
I am bummed that we have to even discuss Apple's anti-free-software tactics in relation to the design of Pd. The only reason why you can't include externals as libdirs on the official iPhone is because of Apple's ridiculous restrictions that are in place solely for the purpose of making the Apple iTunes Store a monopoly. There are no good reasons for those restrictions, unless you are an Apple shareholder and you think profit trumps freedom.
That said, it would be possible to statically link in zexy to rjdj. And if we make Pd load binary classes into a canvas-local namespace, then all of the libraries in Pd-extended could be statically linked in.
How about rjdj for Android and OpenMoko, where there are no such restrictions AFAIK?
.hc
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I am bummed that we have to even discuss Apple's anti-free-software tactics in relation to the design of Pd. The only reason why you can't include externals as libdirs on the official iPhone is because of Apple's ridiculous restrictions that are in place solely for the purpose of making the Apple iTunes Store a monopoly.
The decision, not to bundle the 102MB of externals currently in pd-extended into RjDj has *absolutely nothing* to do with Apple's license policy or any other licence issues: It's a technical decision made by the RjDj team. By keeping RjDj's number of objects limited we aim to avoid a maintainance nightmare and provide everyone with that least common denominator: Pd vanilla and a small number of selected externals. This will be the same for future ports to other platforms.
And personally I made a very similar decision by avoiding to use too many externals on my GNU/Linux machine.
Ciao
On Feb 25, 2009, at 3:11 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I am bummed that we have to even discuss Apple's anti-free-software tactics in relation to the design of Pd. The only reason why you can't include externals as libdirs on the official iPhone is because of Apple's ridiculous restrictions that are in place solely for the purpose of making the Apple iTunes Store a monopoly.
The decision, not to bundle the 102MB of externals currently in pd-extended into RjDj has *absolutely nothing* to do with Apple's license policy or any other licence issues: It's a technical decision made by the RjDj team. By keeping RjDj's number of objects limited we aim to avoid a maintainance nightmare and provide everyone with that least common denominator: Pd vanilla and a small number of selected externals. This will be the same for future ports to other platforms.
And personally I made a very similar decision by avoiding to use too many externals on my GNU/Linux machine.
I am not talking about including files, I am talking about the forced static linking, i.e no dlopen(). It makes sense to me to not include 102 MB of files for rjdj, no complaints about that.
.hc
Ciao
Frank Barknecht
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I am not talking about including files, I am talking about the forced static linking, i.e no dlopen(). It makes sense to me to not include 102 MB of files for rjdj, no complaints about that.
Ah, okay, I misunderstood that. Yeah, the static-linking enforcement sucks big time especially for testing purposes.
Ciao
On Feb 25, 2009, at 3:58 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I am not talking about including files, I am talking about the forced static linking, i.e no dlopen(). It makes sense to me to not include 102 MB of files for rjdj, no complaints about that.
Ah, okay, I misunderstood that. Yeah, the static-linking enforcement sucks big time especially for testing purposes.
So... rjdj for Android! My girlfriend has a developer edition G1, so I am ready! :D I think Android even uses ALSA for sound, so it should just be a matter of building it, then figuring out the distribution.
.hc
----------------------------------------------------------------------------
Access to computers should be unlimited and total. - the hacker ethic
On Wed, 25 Feb 2009, Frank Barknecht wrote:
such a standard library would define an *interface* for standard objects. Where performance is an issue, the interface could alternatively implemented with externals. This also is exemplified in [list]-abs, where personally I use a version of [list-drip] that has zexy's [drip] inside for speed reasons. It behaves exactly like the abstraction version so it doesn't matter if people don't have zexy installed.
i just made a pure-pd [list-drip] that is much much quicker for large lists than your pure pd [list-drip].
For a list of size 32768, I find it to be at least 250 times faster.
For a list of size 4096, it's at least 24 times faster.
See attachment.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Luke Iannini a écrit :
And, here's an example from my own sfruit/ collection:
i try to make some correction to add somes stuff...
gui/ (for extending, interacting with, or working around limitations of the IEMGUIs) ds-gui/ ds-abs/
input keyboard/ hid/
color/ control/ (i'm guessing everyone has enough of these that we'll have to make this finer-grained) dialog/ (these are different manifestations of "dialog boxes" in Pd) gem/
network OSC/
list-abs-extended/ (these are list-abs that require objects not in Pd-vanilla (a restriction laid down by Frank long ago for list-abs)) midi/ sequencing/ signal/ envelope/ mix/ oscillators/
filter effects table
os/
physical_model matrix preset ...
cyrille
just a couple fast general comments (must leave in 15m):
- how about 3 (?) general categories, where everything else is organised? It might be easier to keep everything in mind. - glue/control - singal/audio - GUI (probably there are more main categories?)
- maybe it's time easier to make a puredata.org page for this? and open it to the main list?
will try to give concrete comments later.
Luke Iannini a écrit :
And, here's an example from my own sfruit/ collection:
i try to make some correction to add somes stuff...
gui/ (for extending, interacting with, or working around limitations of the IEMGUIs) ds-gui/ ds-abs/
input keyboard/ hid/
color/ control/ (i'm guessing everyone has enough of these that we'll have to make this finer-grained) dialog/ (these are different manifestations of "dialog boxes" in Pd) gem/
network OSC/
list-abs-extended/ (these are list-abs that require objects not in Pd-vanilla (a restriction laid down by Frank long ago for list-abs)) midi/ sequencing/ signal/ envelope/ mix/ oscillators/
filter effects table
os/
physical_model matrix preset ...
cyrille
On Feb 25, 2009, at 11:35 AM, João Pais wrote:
just a couple fast general comments (must leave in 15m):
- how about 3 (?) general categories, where everything else is
organised? It might be easier to keep everything in mind.
- glue/control
- singal/audio
- GUI
(probably there are more main categories?)
I would add:
- Graphics - Video and something like 'interfacing' where I would put stuff like OSC, UPD , HID device, Wacom tablet, ARDUINO and everything else that can be useful to make acquisition from devices except MIDI.
loic
- maybe it's time easier to make a puredata.org page for this? and
open it to the main list?
will try to give concrete comments later.
Luke Iannini a écrit :
And, here's an example from my own sfruit/ collection:
i try to make some correction to add somes stuff...
gui/ (for extending, interacting with, or working around limitations of the IEMGUIs) ds-gui/ ds-abs/
input keyboard/ hid/
color/ control/ (i'm guessing everyone has enough of these that we'll have to make this finer-grained) dialog/ (these are different manifestations of "dialog boxes" in Pd) gem/
network OSC/
list-abs-extended/ (these are list-abs that require objects not in Pd-vanilla (a restriction laid down by Frank long ago for list-abs)) midi/ sequencing/ signal/ envelope/ mix/ oscillators/
filter effects table
os/
physical_model matrix preset ...
cyrille
-- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 jmmmpais@googlemail.com | skype: jmmmpjmmmp
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
hi, I doubt that these categories will be as hierarchical and structured as proposed here. for example the pdp objects, gridflow and gem(pix and particle+related objects) are good examples for libraries. but zexy and cyclone are libraries where even after so many years I still don't know what some of the objects do or to which library they belong, so here the categorizations could make sense.
still, I think this is much more important for documentation and pedagogical reasans than with relation to avoiding nameclashes or similar, because then we would still end up with two gate objects in the same categorization...
btw I also care more about the functionality of an object than whether it is implemented as a C-external, an abstraction or a lua script. so again a good reference, documentation and communication of available object classes is what I think is missing most.
marius.
with some libraries this
João Pais wrote:
just a couple fast general comments (must leave in 15m):
- how about 3 (?) general categories, where everything else is organised?
It might be easier to keep everything in mind.
- glue/control
- singal/audio
- GUI
(probably there are more main categories?)
- maybe it's time easier to make a puredata.org page for this? and open it
to the main list?
will try to give concrete comments later.
Luke Iannini a écrit :
And, here's an example from my own sfruit/ collection:
i try to make some correction to add somes stuff...
gui/ (for extending, interacting with, or working around limitations of the IEMGUIs) ds-gui/ ds-abs/
input keyboard/ hid/
color/ control/ (i'm guessing everyone has enough of these that we'll have to make this finer-grained) dialog/ (these are different manifestations of "dialog boxes" in Pd) gem/
network OSC/
list-abs-extended/ (these are list-abs that require objects not in Pd-vanilla (a restriction laid down by Frank long ago for list-abs)) midi/ sequencing/ signal/ envelope/ mix/ oscillators/
filter effects table
os/
physical_model matrix preset ...
cyrille
I doubt that these categories will be as hierarchical and structured as proposed here. for example the pdp objects, gridflow and gem(pix and particle+related objects) are good examples for libraries.
as I wrote before, I think that coherent libraries (like the ones you said + vasp and a couple more) exclude themselves from the general external-jungle, and deserve a subcategory of their own. I imagine that the categorising process should help in grouping the objects , but to make a "transparent" and understandable structure - instead of making things more complicated. Maybe each category should have a "vanilla" subsection as well?
but zexy and cyclone are libraries where even after so many years I still don't know what some of the objects do or to which library they belong, so here the categorizations could make sense.
exactly. in the contrary of the before mentioned libraries, these are more groups of externals compassing different groups: glue, math, matrix, ...
still, I think this is much more important for documentation and pedagogical reasans than with relation to avoiding nameclashes or similar, because then we would still end up with two gate objects in the same categorization...
that is also my point (and was actually in the original discussion). but one doesn't avoid the other. in the end of http://puredata.info/dev/PdLibraries I also listed the latest efforts (that I remind of) in this respect. independently of the result of the previous section, an efficient indexing method should also be pursuited - and to remind developpers that documentation is important. maybe this section could go to another page and be discussed independently.
João Pais wrote:
exactly. in the contrary of the before mentioned libraries, these are more groups of externals compassing different groups: glue, math, matrix, ...
please someone explain to me the differences.
this sounds all very nice on a piece of paper, but to which category does [pix_sig2pix~] belong to? - image (or even graphics, since i think that any segregation between graphics and images should _not_ be done anyhow) - signal - glue - misc
mfga.sdr IOhannes
On Feb 27, 2009, at 5:52 AM, IOhannes m zmoelnig wrote:
João Pais wrote:
exactly. in the contrary of the before mentioned libraries, these are more groups of externals compassing different groups: glue, math, matrix, ...
please someone explain to me the differences.
this sounds all very nice on a piece of paper, but to which category does [pix_sig2pix~] belong to?
- image (or even graphics, since i think that any segregation between
graphics and images should _not_ be done anyhow)
- signal
- glue
- misc
mfga.sdr IOhannes
I don't think we should try to come up with an hierarchy in which everything can fit. pix_sig2pix~ can stay in Gem for now. This should be the standard libs of common things, which is currently split across libs like vanilla, zexy, list-abs, creb, etc.
.hc
----------------------------------------------------------------------------
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Hans-Christoph Steiner wrote:
I don't think we should try to come up with an hierarchy in which everything can fit. pix_sig2pix~ can stay in Gem for now. This should be the standard libs of common things, which is currently split across libs like vanilla, zexy, list-abs, creb, etc.
sorry for being unclear, this is clearly a misunderstanding.
i used [pix_sig2pix~] as an example about how categories often fail. it was the first object that came to my mind that clearly belongs into several categories at the same time. there are other objects (within zexy, vanilla, list-abs, creb, you-name-it) that are not simply "glue" or "math", but both and more.
and this is not necessarily a design problem of these objects (though sometimes it might well be).
fortunately loads of object do belong to a simple category, so don't let Gödel stop us from trying to define such categories.
however what i think is relevant is that all categories should be on the same level. e.g. "complex-math" and "signal" are categories on different levels: nothing keeps you from doing complex-math in signal-domain.
otoh, the object interface for doing complex-math in signal-domain might look significantly different than the one in message-domain, or image-domain, or matrix-domain. so, not all objects doing complex-maths (in various domains) should go into the same category "complex-math"
if we have fixed (library-like) categories, then objects should not wander through categories either. otoh, categories should have more than one entry. e.g. if we only have a single bandlimited oscillator, why would we create a category "bandlimitedosc~" rather than just put it into the "osc~" group (btw, should [osc~] itself go into the bandlimitedosc~ group or not?). but when enough blosc~s show up to form a separate category, should we move our original osc into the new group? so people cannot find it anymore.
or should we just have a handful of really big groups? who would be willing to maintain them (e.g. the "fx~" group)
mf.ar IOhannes
On Fri, 27 Feb 2009, IOhannes m zmoelnig wrote:
i used [pix_sig2pix~] as an example about how categories often fail. it was the first object that came to my mind that clearly belongs into several categories at the same time. there are other objects (within zexy, vanilla, list-abs, creb, you-name-it) that are not simply "glue" or "math", but both and more. and this is not necessarily a design problem of these objects (though sometimes it might well be).
I agree: see also:
http://lists.puredata.info/pipermail/pd-list/2007-07/051652.html http://lists.puredata.info/pipermail/pd-list/2007-07/051659.html http://lists.puredata.info/pipermail/pd-list/2007-07/051768.html ... and more mails in that thread.
fortunately loads of object do belong to a simple category, so don't let Gödel stop us from trying to define such categories.
What's Gödel have to do with it at all?
(I don't necessarily agree with the rest of your mail.)
otoh, the object interface for doing complex-math in signal-domain might look significantly different than the one in message-domain, or image-domain, or matrix-domain. so, not all objects doing complex-maths (in various domains) should go into the same category "complex-math"
as much as possible, interfaces that are not the same about things that are, should be transformable by a function that takes an interfaces and turns it into another interface. This is so that people can guess how a class works, from the knowledge of how a similar class works. It can save on the amount of help files too. Ideally, we'd save on the number of classes, though.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
may I suggest the following category structure
Pd world series top 40 frank's special blend other utilities objects that might crash the ones I almost never use not allowed during war ...
marius.
2009/2/27 Mathieu Bouchard matju@artengine.ca:
On Fri, 27 Feb 2009, IOhannes m zmoelnig wrote:
i used [pix_sig2pix~] as an example about how categories often fail. it was the first object that came to my mind that clearly belongs into several categories at the same time. there are other objects (within zexy, vanilla, list-abs, creb, you-name-it) that are not simply "glue" or "math", but both and more. and this is not necessarily a design problem of these objects (though sometimes it might well be).
I agree: see also:
http://lists.puredata.info/pipermail/pd-list/2007-07/051652.html http://lists.puredata.info/pipermail/pd-list/2007-07/051659.html http://lists.puredata.info/pipermail/pd-list/2007-07/051768.html ... and more mails in that thread.
fortunately loads of object do belong to a simple category, so don't let Gödel stop us from trying to define such categories.
What's Gödel have to do with it at all?
(I don't necessarily agree with the rest of your mail.)
otoh, the object interface for doing complex-math in signal-domain might look significantly different than the one in message-domain, or image-domain, or matrix-domain. so, not all objects doing complex-maths (in various domains) should go into the same category "complex-math"
as much as possible, interfaces that are not the same about things that are, should be transformable by a function that takes an interfaces and turns it into another interface. This is so that people can guess how a class works, from the knowledge of how a similar class works. It can save on the amount of help files too. Ideally, we'd save on the number of classes, though.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Fri, 27 Feb 2009, marius schebella wrote:
Pd world series top 40 frank's special blend other utilities objects that might crash the ones I almost never use not allowed during war
Other possible taxonomy: three categories total: good/ bad/ ugly/
Other possible taxonomy: five categories total: easy/ normal/ difficult/ expert/ ninja/
Other possible taxonomy: five categories total: lime/ strawberry/ blueberry/ grape/ tangerine/
Other possible taxonomy: two categories total: country/ western/
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Fri, Feb 27, 2009 at 3:58 PM, Mathieu Bouchard matju@artengine.ca wrote:
On Fri, 27 Feb 2009, marius schebella wrote:
Pd world series top 40 frank's special blend other utilities objects that might crash the ones I almost never use not allowed during war
Other possible taxonomy: three categories total: good/ bad/ ugly/
Other possible taxonomy: five categories total: easy/ normal/ difficult/ expert/ ninja/
Other possible taxonomy: five categories total: lime/ strawberry/ blueberry/ grape/ tangerine/
Other possible taxonomy: two categories total: country/ western/
Haha, as much as I would enjoy this...
Do you or Marius have any concrete suggestions as to what wold be a better approach? You must at least admit things could be better, no?
I just took a look at Max/MSP and they have a nice tagging system, as well as an excellent configurable filter on their file browser that ends up being a pretty elegant solution to many of these problems. Perhaps going the route of adding parsable tags to object help patches (e.g. a comment containing ##os ##midi ##oscillator (hm, quite an odd object)) that can then be read back by the help-browser is more what you're suggesting (I got that feeling from the threads you linked Mathieu). A good bit of work there though, and it doesn't do anything for namespace issues, just ease-of-discovery.
But, I also do not think that the difficulties you guys are enumerating are enough to condemn the entire idea of organizing things more logically than by author. I can at least offer Python as example of an extremely well-organized set of libaries - I don't know the history of /how/ they came to be that way but i can easily "import functools, urllib, os, simpleosc, midi, Image, pickle", and it works phenomenally well.
Best Luke
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
I just took a look at Max/MSP and they have a nice tagging system, as well as an excellent configurable filter on their file browser that ends up being a pretty elegant solution to many of these problems. Perhaps going the route of adding parsable tags to object help patches (e.g. a comment containing ##os ##midi ##oscillator (hm, quite an odd object)) that can then be read back by the help-browser is more what you're suggesting (I got that feeling from the threads you linked Mathieu).
I think, that's a good aproach (although it doesn't solve any namespacing issues) and a start for this is already existing in the [pd META] subpatch that you can find in some help patches in the svn.
Documentation and categorization IMO should live as closely as possible to where the action is, i.e. in a help file or embedded in an abstraction/external.
BTW: That is (and already was in the discussion about it at pd~conv Montreal) my main problem with pdpedia: IMO a Pd doc wiki takes the reference documention too far away from the files. I'm pretty sure, that people will rather add a [pd META] or so to their help files than go and edit a pdpedia page. In turn, a pdpedia page can parse and read out the META data from a help file - in fact, most of the useful stuff in pdpedia has been generated that way. The success of comment-generated docs or Python's docstrings illustrate my reasoning.
Ciao
I'd suggest simply adding a commemnt like "tags: os midi oscillator" - then we can just "grep tags: ../5.doc/*.pd | grep -i midi" to quickly get a list of relevant patches. It would also help to work up a list of commonly used tags so new help patches can re-use existing ones where possible - for instance, either "signal" or "tilde" or "~" but not chosen at random from the three :)
cheers Miller
On Sat, Feb 28, 2009 at 03:11:31PM +0100, Frank Barknecht wrote:
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
I just took a look at Max/MSP and they have a nice tagging system, as well as an excellent configurable filter on their file browser that ends up being a pretty elegant solution to many of these problems. Perhaps going the route of adding parsable tags to object help patches (e.g. a comment containing ##os ##midi ##oscillator (hm, quite an odd object)) that can then be read back by the help-browser is more what you're suggesting (I got that feeling from the threads you linked Mathieu).
I think, that's a good aproach (although it doesn't solve any namespacing issues) and a start for this is already existing in the [pd META] subpatch that you can find in some help patches in the svn.
Documentation and categorization IMO should live as closely as possible to where the action is, i.e. in a help file or embedded in an abstraction/external.
BTW: That is (and already was in the discussion about it at pd~conv Montreal) my main problem with pdpedia: IMO a Pd doc wiki takes the reference documention too far away from the files. I'm pretty sure, that people will rather add a [pd META] or so to their help files than go and edit a pdpedia page. In turn, a pdpedia page can parse and read out the META data from a help file - in fact, most of the useful stuff in pdpedia has been generated that way. The success of comment-generated docs or Python's docstrings illustrate my reasoning.
Ciao
Frank
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
This would be a good place to start. I think having a [pd META] subpatch will make accurate parsing easier, and allow for other types of meta data to be easily added. That's what we did with the PDDP reference patch.
As for tagging, as long as it is not too hard to add more tags later, I think that we don't have to spend a ton of time trying to come up with the perfect set of tags.
.hc
On Feb 28, 2009, at 10:28 AM, Miller Puckette wrote:
I'd suggest simply adding a commemnt like "tags: os midi oscillator" - then we can just "grep tags: ../5.doc/*.pd | grep -i midi" to quickly get a list of relevant patches. It would also help to work up a list of commonly used tags so new help patches can re-use existing ones where possible - for instance, either "signal" or "tilde" or "~" but not chosen at random from the three :)
cheers Miller
On Sat, Feb 28, 2009 at 03:11:31PM +0100, Frank Barknecht wrote:
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
I just took a look at Max/MSP and they have a nice tagging system, as well as an excellent configurable filter on their file browser that ends up being a pretty elegant solution to many of these problems. Perhaps going the route of adding parsable tags to object help patches (e.g. a comment containing ##os ##midi ##oscillator (hm, quite an odd object)) that can then be read back by the help-browser is more what you're suggesting (I got that feeling from the threads you linked Mathieu).
I think, that's a good aproach (although it doesn't solve any namespacing issues) and a start for this is already existing in the [pd META] subpatch that you can find in some help patches in the svn.
Documentation and categorization IMO should live as closely as possible to where the action is, i.e. in a help file or embedded in an abstraction/external.
BTW: That is (and already was in the discussion about it at pd~conv Montreal) my main problem with pdpedia: IMO a Pd doc wiki takes the reference documention too far away from the files. I'm pretty sure, that people will rather add a [pd META] or so to their help files than go and edit a pdpedia page. In turn, a pdpedia page can parse and read out the META data from a help file - in fact, most of the useful stuff in pdpedia has been generated that way. The success of comment- generated docs or Python's docstrings illustrate my reasoning.
Ciao
Frank
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
kill your television
This would be a good place to start. I think having a [pd META] subpatch will make accurate parsing easier, and allow for other types of meta data to be easily added. That's what we did with the PDDP reference patch.
but in case the externals get organised through function (instead of author/lib folder), the meta patches won't make much sense. how about frank's (standard) idea of using the text files with short description? each author/lib could have his name on that file - jmmmp.txt, hid.txt, etc. Or adding a string, like lib-jmmmp.txt, lib-hid.txt, ...
btw, I never noticed why the meta patches were there. are they already being used in any way, or that's a work in progress?
As for tagging, as long as it is not too hard to add more tags later, I think that we don't have to spend a ton of time trying to come up with the perfect set of tags.
I would add that in general the discussion is slowing up a bit (that might be the normal pace for mail discussions). How about putting a small page with the most relevant sugestions, in order to try to make a decision? Or leave it for the next time enough pd-people meet in the same room (with computers and no beer)?
On Mar 3, 2009, at 6:10 AM, João Pais wrote:
This would be a good place to start. I think having a [pd META] subpatch will make accurate parsing easier, and allow for other types of meta data to be easily added. That's what we did with the PDDP reference patch.
but in case the externals get organised through function (instead of author/lib folder), the meta patches won't make much sense. how about frank's (standard) idea of using the text files with short description? each author/lib could have his name on that file - jmmmp.txt, hid.txt, etc. Or adding a string, like lib-jmmmp.txt, lib- hid.txt, ...
btw, I never noticed why the meta patches were there. are they already being used in any way, or that's a work in progress?
The [pd META] creates a single place to put the data in the help file, which is already the central reference for each object. Once the data is parsed, then it can be used and organized in any structure, like per-author, per-library, per-tag, per-function, etc.
As for tagging, as long as it is not too hard to add more tags later, I think that we don't have to spend a ton of time trying to come up with the perfect set of tags.
I would add that in general the discussion is slowing up a bit (that might be the normal pace for mail discussions). How about putting a small page with the most relevant sugestions, in order to try to make a decision? Or leave it for the next time enough pd-people meet in the same room (with computers and no beer)?
I say make a "meta" wiki page on http://puredata.info/dev and start adding info.
.hc
----------------------------------------------------------------------------
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
On Sat, 28 Feb 2009, Frank Barknecht wrote:
BTW: That is (and already was in the discussion about it at pd~conv Montreal) my main problem with pdpedia: IMO a Pd doc wiki takes the reference documention too far away from the files.
I agree with that. I used to consider an HTML-based manual as the reference documentation for my externals, but found out it's a real bad idea. It's not just that moving info back and forth from two sets of documentation is long and error-prone, it's also boring and it's something nothing wants to do for free.
This means that unless there are special tools for feeding back info from pdpedia, then pdpedia shouldn't be edited directly, and could even be closed or turned into a bunch of static generated HTML without a CMS behind it; and then all the effort should go towards improving how the helpfiles are to be made and how they are to be interacted with.
(Well, it's also possible to just stop using help files, but 99% of the users would hate it)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Mar 2, 2009, at 11:01 PM, Mathieu Bouchard wrote:
On Sat, 28 Feb 2009, Frank Barknecht wrote:
BTW: That is (and already was in the discussion about it at pd~conv Montreal) my main problem with pdpedia: IMO a Pd doc wiki takes the reference documention too far away from the files.
I agree with that. I used to consider an HTML-based manual as the reference documentation for my externals, but found out it's a real bad idea. It's not just that moving info back and forth from two sets of documentation is long and error-prone, it's also boring and it's something nothing wants to do for free.
This means that unless there are special tools for feeding back info from pdpedia, then pdpedia shouldn't be edited directly, and could even be closed or turned into a bunch of static generated HTML without a CMS behind it; and then all the effort should go towards improving how the helpfiles are to be made and how they are to be interacted with.
(Well, it's also possible to just stop using help files, but 99% of the users would hate it)
pdpedia is not meant to be help patches, instead it is info about the object and things like links to related algorithms, video demos, etc.
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
All information should be free. - the hacker ethic
On Mon, 2 Mar 2009, Hans-Christoph Steiner wrote:
On Mar 2, 2009, at 11:01 PM, Mathieu Bouchard wrote:
(Well, it's also possible to just stop using help files, but 99% of the users would hate it)
pdpedia is not meant to be help patches, instead it is info about the object and things like links to related algorithms, video demos, etc.
Perhaps you understand yourself, but help patches are meant to contain "info about the object" and in some cases it contains links to related pages. There's nothing about links that make them off-topic for a help patch. What is that [pddplink] thing for, anyway?
http://wiki.puredata.info/en/pddplink
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Mar 3, 2009, at 9:39 AM, Mathieu Bouchard wrote:
On Mon, 2 Mar 2009, Hans-Christoph Steiner wrote:
On Mar 2, 2009, at 11:01 PM, Mathieu Bouchard wrote:
(Well, it's also possible to just stop using help files, but 99% of the users would hate it)
pdpedia is not meant to be help patches, instead it is info about the object and things like links to related algorithms, video demos, etc.
Perhaps you understand yourself, but help patches are meant to contain "info about the object" and in some cases it contains links to related pages. There's nothing about links that make them off- topic for a help patch. What is that [pddplink] thing for, anyway?
Well, the dogmatic vanilla users would not be happy. Plus it is not easy to contribute to a help patch as compared to a wiki. That's the idea anyway.
.hc
----------------------------------------------------------------------------
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
On Tue, 3 Mar 2009, Hans-Christoph Steiner wrote:
On Mar 3, 2009, at 9:39 AM, Mathieu Bouchard wrote:
Perhaps you understand yourself, but help patches are meant to contain "info about the object" and in some cases it contains links to related pages. There's nothing about links that make them off-topic for a help patch. What is that [pddplink] thing for, anyway?
Well, the dogmatic vanilla users would not be happy.
So, do you want to serve the dogmatic vanilla users, or do you want to serve everybody? If you serve everybody, the dogmatic vanilla users still end up being able to paste a link from a dashed objectbox anyway, so, what's the problem with that?
Plus it is not easy to contribute to a help patch as compared to a wiki. That's the idea anyway.
The problem is that it is not easy to contribute to a help patch as compared to a wiki. Therefore, things must be done so that it becomes as easy to contribute to a help patch as it is to contribute to a wiki.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Sat, 28 Feb 2009, Luke Iannini wrote:
Do you or Marius have any concrete suggestions as to what wold be a better approach? You must at least admit things could be better, no?
Well, first, we need to realise what our values and tastes are. Then we can agree on a broad meaning of the word «better», contextually speaking. Then we can research possible solutions, and rate them in terms of their upsides and downsides. Eventually, when we have found a solution that is more better than it is worse, I can admit things could be better. Until then, there is only hope and cheerleading. Well, that's already a good thing and it's very important in order to get things moving; but having a fact in your hand and being able to _admit_ it, now this is some kind of achievement.
I just took a look at Max/MSP and they have a nice tagging system,
I do support tagging rather than mutually-exclusive categories. I won't bother looking at Max/MSP's tagging system though. If there's anything in it that people really want, I'll hear about it.
Perhaps going the route of adding parsable tags to object help patches (e.g. a comment containing ##os ##midi ##oscillator (hm, quite an odd object)) that can then be read back by the help-browser is more what you're suggesting (I got that feeling from the threads you linked Mathieu).
Not necessarily that way. They could be there, but they could also be in a file reserved for that purpose. That would be much faster to load and wouldn't require a cache, but that's not the main reasons. It would be quicker to have an overview of a whole library (or of the whole system) by looking at a single file, and quicker to edit it as well. It's also better to at least allow tag files outside of the library packages themselves, and allow them to superimpose transparently to packages' tags, because then you can have user-defined tags (a user's way of taking notes) and at the same time a package can upgrade its own tag files without interfering much with the user.
A good bit of work there though, and it doesn't do anything for namespace issues, just ease-of-discovery.
Alas, even namespaces don't do much for namespace issues. Look at how, for example, Java Swing got its namespace done. You have to import Swing, and then nearly everything in it has a J prefix to it. Why? Because namespaces are largely ineffectual. You put enough classes in the same namespace so that you don't have to write too many import-directives. Then you do use the import-directives to put together the combination of libraries that you will use to do something. As things that we do get more complex, more libraries are needed at once. Eventually, you get a clash anyway. I still agree that there are less clashes with namespaces than without, but they seem to be a lot of effort for the amount of payback.
Tags don't all have to do with ease-of-discovery. They can be used to simplify the documentation itself, as for example any class tagged "stdinlets" has one hot inlet and N cold inlets that work the usual way, and "stdoutlets" is likewise a shortcut to not have to explain that a class sends out on all of its outlets at once, right-to-left, like [unpack] does. This tagging concept can cut significant amounts of documentation in a way PDDP never quite envisioned.
Furthermore, tags can also be used for automatic testing, as for example, if a class has the stdinlets or stdoutlets property, that is something that can be verified. This can be used to generate a wrapper-abstraction for a class, that would check anything about a class that can be reasonably checked automatically, so that when you are using the class through the wrapper, the wrapper is continuously checking that the tags are correct (for any tags that have specific tests associated to them).
Furtherfurthermore, tags can also be used for design. If the automatic tests are already associated to tags, then those tags get to shape the design of classes, as we try to make classes conform to tags, compress the documentation by making it use tags more, and keep the number of different tags low so that tags stay useful and easy to browse through.
But, I also do not think that the difficulties you guys are enumerating are enough to condemn the entire idea of organizing things more logically than by author. I can at least offer Python as example of an extremely well-organized set of libaries - I don't know the history of /how/ they came to be that way but i can easily "import functools, urllib, os, simpleosc, midi, Image, pickle", and it works phenomenally well.
But what nameclashes does it fix? I mean, you could also have a Python that tries doing away with imports, would load anything on demand, and then, what would the nameclashes be?
A major difference between something like Python and something like Pd, is that in the former, classes already act as a namespacing device, and methods tend to be many-per-class. In the latter, however, classes don't tend to be used as such, the methods are few-per-class (e.g. left-inlet has float, set, bang, right-inlet has just float), so the role of a class in Pd is closer to that of a method in Python, and thus you have a much greater proliferation of classes in Pd for the same amount of functionality.
So, would it be the case that making Pd's namespaces like Python's would make Pd's namespaces really feel like Python's?
Namespaces are this strange beast: the more nameclashes would be possible, the more nameclashes are solved by namespaces, but the more nameclashes happen anyway because of conflicting imports, so in situations where you just don't want to see any clashes at all (an all-or-nothing proposition), there's not so much middle-ground in which namespaces both really address a problem (nameclashes would be possible) and successfully so (nameclashes are all resolved).
On Feb 27, 2009 at 3:58 PM, Mathieu Bouchard matju@artengine.ca wrote:
good/ bad/ ugly/
note that there is really a programme that uses those categories in the package management: GStreamer.
easy/ normal/ difficult/ expert/ ninja/
I wrote this because of the tendency of graphical-user-interfaces (outside of Pd) to have an "advanced" section, in which all the important things are. (All the other important things are, of course, removed from the UI completely, as they could "confuse" the user).
lime/ strawberry/ blueberry/ grape/ tangerine/
When the G3/333 iMac came out, choosing a computer had never been that superficial. It hasn't really been ever since.
country/ western/
When I was a kid, in my hometown, bars played *both* kinds of music. Nowadays, thanks to cataclysms such as illegal fishing and Brigitte Bardot, my hometown had to recycle in tourism and open itself to slightly more diverse bars...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Luke Iannini wrote:
On Fri, Feb 27, 2009 at 3:58 PM, Mathieu Bouchard matju@artengine.ca wrote:
On Fri, 27 Feb 2009, marius schebella wrote:
Pd world series top 40 frank's special blend other utilities objects that might crash the ones I almost never use not allowed during war
Other possible taxonomy: three categories total: good/ bad/ ugly/
[...]
Haha, as much as I would enjoy this...
Do you or Marius have any concrete suggestions as to what wold be a better approach?
I still believe in a flat space class pool. all objects should live inside the extra folder.
there may be two exceptions to that; sometimes I want to load a library, and sometimes I want to make use of name spaces. both cases are imho not related to a categorization system, but to the general question "how can I identify every object in my patch?" (UIDification).
why/when do I want to load a library * abbreviated objects (they're only available if the obj class was loaded before) * libraries/objects that provide additional features other than the object itself (for example loaders, ..)
why/when do I want to make use of name spaces * name clashes. from the past I think there are 10-20 external objects that have the same name, but different functionality. and there are hundreds of abstractions that have the same name as an external object.
You must at least admit things could be better, no?
yes, right now objects are split up into "libraries" that are strongly developer oriented, I think a pd-distro like pd-x should provide a selection (all?) of these objects, unify them, document them and get rid of the folder structure.
btw. one issue that is important (maybe not now, but some time in the future) for the categorization discussion was not mentioned yet: different libraries have different licenses. that would make some good categories.
marius, who deleted 3 pages of additional text to make this email very short.
I just took a look at Max/MSP and they have a nice tagging system, as well as an excellent configurable filter on their file browser that ends up being a pretty elegant solution to many of these problems. Perhaps going the route of adding parsable tags to object help patches (e.g. a comment containing ##os ##midi ##oscillator (hm, quite an odd object)) that can then be read back by the help-browser is more what you're suggesting (I got that feeling from the threads you linked Mathieu). A good bit of work there though, and it doesn't do anything for namespace issues, just ease-of-discovery.
But, I also do not think that the difficulties you guys are enumerating are enough to condemn the entire idea of organizing things more logically than by author. I can at least offer Python as example of an extremely well-organized set of libaries - I don't know the history of /how/ they came to be that way but i can easily "import functools, urllib, os, simpleosc, midi, Image, pickle", and it works phenomenally well.
Best Luke
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hi,
João Pais wrote:
exactly. in the contrary of the before mentioned libraries, these are more groups of externals compassing different groups: glue, math, matrix, ...
please someone explain to me the differences.
this sounds all very nice on a piece of paper, but to which category does [pix_sig2pix~] belong to?
- image (or even graphics, since i think that any segregation between
graphics and images should _not_ be done anyhow)
- signal
- glue
- misc
I wouldn't try to be very radical (or anal) here. I wrote somewhere else (but don't remeber where) that cohese libraries - like Gem, Pdp, vasp, and maybe others - already close themselves from the outside world, so they should remain as a group, and the group inserted in the best main category above them. check the page now, actually I also joined both video/graphics categories, and put some subcategories in. As for individual cases, they should be checked case to case. Gem has signal objects, but since it's goes is video, it should go to the video section.
I think this doesn't affect cohese libraries that much, because it makes no sense to split them apart. but it will help with libraries that are just a group of lots of utilities for different categories - zexy, etc etc, also jmmmp, etc. For example, the IEM libs split themselves up at some point, now we have iem-gui, iem-matrix, ...
One thing I was thinking about recently is whether we need a hierarchy of classes. In Object-Oriented Programming, there is hierarchy of classes as part of the basis of the language. There is no hierarchy of classes in Pd so it seems to me that there should also be no hierarchy in the namespaces (FYI: this is contrary to something I proposed a while back).
Basically, I mean we should not have a library structure like this:
audio audio/math audio/filters audio/oscillators audio/oscillators/bwlimited
Instead, it would be a one level namespace, to keep things simple, so maybe something like this:
audio audiomath filters oscillators bloscillators
Or even better, have more descriptive, fun and hopefuilly more memorable names, like: simpillators blocycle
This isn't really a proposal of any kind, but more a discussion point.
.hc
On Feb 26, 2009, at 6:21 PM, marius schebella wrote:
hi, I doubt that these categories will be as hierarchical and structured as proposed here. for example the pdp objects, gridflow and gem(pix and particle+related objects) are good examples for libraries. but zexy and cyclone are libraries where even after so many years I still don't know what some of the objects do or to which library they belong, so here the categorizations could make sense.
still, I think this is much more important for documentation and pedagogical reasans than with relation to avoiding nameclashes or similar, because then we would still end up with two gate objects in the same categorization...
btw I also care more about the functionality of an object than whether it is implemented as a C-external, an abstraction or a lua script. so again a good reference, documentation and communication of available object classes is what I think is missing most.
marius.
with some libraries this
João Pais wrote:
just a couple fast general comments (must leave in 15m):
- how about 3 (?) general categories, where everything else is
organised? It might be easier to keep everything in mind.
- glue/control
- singal/audio
- GUI
(probably there are more main categories?)
- maybe it's time easier to make a puredata.org page for this? and
open it to the main list?
will try to give concrete comments later.
Luke Iannini a écrit :
And, here's an example from my own sfruit/ collection:
i try to make some correction to add somes stuff...
gui/ (for extending, interacting with, or working around limitations of the IEMGUIs) ds-gui/ ds-abs/
input keyboard/ hid/
color/ control/ (i'm guessing everyone has enough of these that we'll have to make this finer-grained) dialog/ (these are different manifestations of "dialog boxes" in Pd) gem/
network OSC/
list-abs-extended/ (these are list-abs that require objects not in Pd-vanilla (a restriction laid down by Frank long ago for list- abs)) midi/ sequencing/ signal/ envelope/ mix/ oscillators/
filter effects table
os/
physical_model matrix preset ...
cyrille
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Access to computers should be unlimited and total. - the hacker ethic
One thing I was thinking about recently is whether we need a hierarchy of classes. In Object-Oriented Programming, there is hierarchy of classes as part of the basis of the language. There is no hierarchy of classes in Pd so it seems to me that there should also be no hierarchy in the namespaces (FYI: this is contrary to something I proposed a while back).
I myself can't do many comparations with programming languages, because I'm not a programmer. can program only Pd, not C or anything else. so what I say is more to do with logic and common sense than making references to concrete standards.
Basically, I mean we should not have a library structure like this:
audio audio/math audio/filters audio/oscillators audio/oscillators/bwlimited
Instead, it would be a one level namespace, to keep things simple, so maybe something like this:
audio audiomath filters oscillators bloscillators
Or even better, have more descriptive, fun and hopefuilly more memorable names, like: simpillators blocycle
This isn't really a proposal of any kind, but more a discussion point.
it's good to consider it, but I think it makes it more complicated. if you have a root division of control / audio / graphics / ect., it's much easier to find other lower categories of objects. and that filters information and saves time - if one is looking for band-limited-oscillators, he knows he should to go to audio->oscillators first. and not look at once at 30+ categories until he finds whatever he wants to.
about "descriptive, fun and hopefuilly more memorable names", I've also seen this a bit in the pdpedia, and was on my mind: if there are already standards for objects, I don't know if it's efficient to reinvent the wheel (and give it a funny shape). Pd (or any language) should also be ready for scientific use, and in that way comply with the already existing standards. Or I could make up new names based on portuguese translation, that would be funny.
I guess this suggestion from you was just to make sure this case gets considered? (and I hope, rejected?)
a few years ago i started to scratch together a php/mysql based database for pure-data documentation, the project became eclipsed by the push to the wikimedia based pdpedia, so i didn't get much further than documenting vanilla objects, and integrating the csv doc by marius schebella. but the one thing i did do was break the list into categories and subcategories.
my intention at the time was to collate enough information in the database to be able to publish the entire thing as a pdf reference, but i was also thinking of integrating the database into desiredata for contextual help. the most information present is for the vanilla set (pd-lib) with info on the internal methods for inlets and outlets.
the tool itself while far from complete was useful enough as a quick reference guide, especially when i wasn't connected to the internet.. it sports a zippy interface that 'expands' dynamically, and basically attempts to resemble 'help-intro.pd'. anyhow it was lost on an old disk image, but i have managed to revive it and install it on my current machine..
i don't know if its useful to anyone, but its relevant to this thread and documents my interpretation of object categories.. so if its of interest, please point your browser to: http://dmotd.dyndns.org/pd/objects.php i've also made a backup of the sql table: http://dmotd.dyndns.org/pd/pure-data.sql OR http://dmotd.dyndns.org/pd/pure-data.csv
(i don't have access to an actual server at present, so i will leave this open for a few days.. please be kind to my machine!)
cheers, dmotd
-
cyrille henry -
dmotd -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
João Pais -
Loic Kessous -
Luke Iannini -
marius schebella -
Mathieu Bouchard -
Miller Puckette