Re: [PD-dev] Proposals for object categories
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)? ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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? http://wiki.puredata.info/en/pddplink 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
On Fri, Feb 27, 2009 at 3:58 PM, Mathieu Bouchard ma...@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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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
Re: [PD-dev] Proposals for object categories
Luke Iannini wrote: On Fri, Feb 27, 2009 at 3:58 PM, Mathieu Bouchard ma...@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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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, ... ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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?) ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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
Re: [PD-dev] Proposals for object categories
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 ma...@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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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
Re: [PD-dev] Proposals for object categories
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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 BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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
Re: [PD-dev] Proposals for object categories
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 -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ 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
Re: [PD-dev] Proposals for object categories
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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 BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at
Re: [PD-dev] Proposals for object categories
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 -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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
Re: [PD-dev] Proposals for object categories
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 -- Frank Barknecht ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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 -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
