Re: [PD] [dsplib]: how should it be maintained?
Le mercredi 20 juin 2007 à 14:49 +0200, Roman Haefeli a écrit : as for know, i try to keep things as simple as possible, so that anyone can use netpd without having technical issues (also pd-extended users, course) That must explain why netpd is working so good, thanks dear coordinator, ;). as long as it works, it is fun. and i do believe, that - when considering doing music - you already can do a lot with the actual externals and pd's builtin objects, it is only a matter of how to use them. roman ___ Der frhe Vogel fngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
Hallo, Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote: Here is a link to the pdmtl list of files. It has quite a few objects, and a lot of dsp ones too. I am all for adopting this framework, since it is already semi-established with users. http://wiki.dataflow.ws/PdMtlAbstractions/Contents I think, things like pdmtl, netpd or mMm already are one level higher than what I thought a dsp/tilde collection aims for. For example on that wiki page you see, that a several of the patches are based on other people's patches: For example you can find some abstractions Andy posted here in it, and they are used in mMm as well. As another example I also found some of my abstractions posted to the list in mMm. (Which totally unrelated reminds me to report a bug that [list/cog] of pdmtl does a wrong calculation of the center of gravity. Anybody knows who wrote that? Please see list-centroid.pd for the correct calculation.) Anyway, the tilde/dsp-lib in my view just tries to collect these abstractions posted to the list or hidden in some larger application or framework in one place, so that other people can reuse them again for their own work, either as abtractions or by copying them over pdmtl-style. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On Tue, 2007-06-19 at 17:52 -0500, Kyle Klipowicz wrote: I am curious, has anyone ever vandalized the netpd patches during a jam? Fortunately, no. i once kind of vandalized. a person left the computer and we needed to restart every client for some reason. because that person was not reachable, i wrote a patch, that when opened, did nothing on every client, but on that specific client quit pd. Seriously, vandalizing in netpd wouldn't be much fun, because it is so easy. it would be like robbing a grandmother. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
it would be like robbing a grandmother. sounds like fun to me! ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On Wed, 2007-06-20 at 20:58 +0900, hard off wrote: it would be like robbing a grandmother. sounds like fun to me! bad guy! in that case, you are invited to vandalize in netpd a bit, just for your fun's sake ;-) roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On Wed, 2007-06-20 at 10:32 +0200, Frank Barknecht wrote: Hallo, Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote: Here is a link to the pdmtl list of files. It has quite a few objects, and a lot of dsp ones too. I am all for adopting this framework, since it is already semi-established with users. http://wiki.dataflow.ws/PdMtlAbstractions/Contents I think, things like pdmtl, netpd or mMm already are one level higher than what I thought a dsp/tilde collection aims for. my thoughts as well. Anyway, the tilde/dsp-lib in my view just tries to collect these abstractions posted to the list or hidden in some larger application or framework in one place, so that other people can reuse them again for their own work, either as abtractions or by copying them over pdmtl-style. my thoughts as well. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On Wed, 2007-06-20 at 04:50 +0200, Patco wrote: It's true that things might be a lot more complicated if net-pd users starts to build net-pd objects with using pd-extended distro, and jam with people that are using net-pd distro. things are more complicated then, absolutely, but: a) i don't want to restrict the use of netpd b) more important: i cannot restrict the use of netpd. I guess you start to see how it might be important to have a kind of coordinator for the patch sharing. i disagree, that this would be necessary. netpd just states that it could be assumed, that on every client zexy, maxlib, iemmatrix, iemlib1, iemlib2, iemabs, iem_t3_lib (the latter - like zexy - seems to be obsolete now) is installed, let's say a group of people starts a project based on gem/netpd, i wouldn't want to hinder them in any way. also i do not say, that netpd will always stick with these externals in the future and possibly the policy will change, so that it will be usual to use any external thanks to pd-extended. as for know, i try to keep things as simple as possible, so that anyone can use netpd without having technical issues (also pd-extended users, course). as long as it works, it is fun. and i do believe, that - when considering doing music - you already can do a lot with the actual externals and pd's builtin objects, it is only a matter of how to use them. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On Tue, 2007-06-19 at 01:09 +0200, Roman Haefeli wrote: On Mon, 2007-06-18 at 23:34 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: one question still remains: how is it organized? will some mercyful person voluntarly collect the dsp abs and check it in into cvs? or shall we give cvs write access to every interested author? I'd rather not give anyone write permissions, as we're already are quite a huge number of developers. I would give permissions to you, however, also for netpd. ;) I'd volunteer to check in the dsp abstractions. May we could collect them on puredata.info first. Then from time to time I or someone else would check in the latest versions into CVS. yo, i put my stuff on: http://puredata.info/Members/rdz/ yo, i had a talk with syntax_the_nerd (christopher) and he started to port his dsp-stuff into a collection as well [1]. as for now, there are only two abstractions in there (basically he wanted to make an example how he would do it). however, he added some info to his patches, that makes a lot of sense in my eyes and might be essential for a good lib of that kind. he tagged each patch and according helppatch with: Name (of the patch/abstraction) (Name of the) Author Binary deps (pd-version, externals) Patch deps (abs-collection or single abs) License (e.g. Gnu GPL) though it is also my opinion, that in the first place it is important that things get done and in the second place how they are done, i think that this bit information is essential and should be easy to do. what do you think? roman [1] http://puredata.info/Members/syntax_the_nerd ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: Name (of the patch/abstraction) (Name of the) Author Binary deps (pd-version, externals) Patch deps (abs-collection or single abs) License (e.g. Gnu GPL) though it is also my opinion, that in the first place it is important that things get done and in the second place how they are done, i think that this bit information is essential and should be easy to do. I think, there is the [pd META] format in pd-extended, which could be reused for that. For dependencies, I'd prefer [declare], as that gives a bit more functionality and may give more in its evolution. For now it would just contain the meta-information. For a license I actually would prefer the same license for everything in that collection: the Pd license. But that's of course a hairy issue. In general I think, this META information would be good to have and it could be added or checked by the one checking in the abstractions to the CVS. Some other things: A tricky issue may be abstractions that use other custom abstractions. I think, a subdirectory for these sub-abstractions would be good to have, so that the namespace doesn't get polluted. And then: Should we discuss the namei? dsp may be a bit misleading or too specific. Some random ideas: sig, tilde, play. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On Tue, 2007-06-19 at 17:11 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: Name (of the patch/abstraction) (Name of the) Author Binary deps (pd-version, externals) Patch deps (abs-collection or single abs) License (e.g. Gnu GPL) though it is also my opinion, that in the first place it is important that things get done and in the second place how they are done, i think that this bit information is essential and should be easy to do. I think, there is the [pd META] format in pd-extended, which could be reused for that. For dependencies, I'd prefer [declare], as that gives a bit more functionality and may give more in its evolution. For now it would just contain the meta-information. For a license I actually would prefer the same license for everything in that collection: the Pd license. But that's of course a hairy issue. In general I think, this META information would be good to have and it could be added or checked by the one checking in the abstractions to the CVS. Some other things: A tricky issue may be abstractions that use other custom abstractions. I think, a subdirectory for these sub-abstractions would be good to have, so that the namespace doesn't get polluted. And then: Should we discuss the namei? dsp may be a bit misleading or too specific. Some random ideas: sig, tilde, play. i'd vote for 'tilde', since this has a very open meaning. i forgot to mention, my and syntax' abstractions use a version tag of the format: [version x.x.x( (where x can be any integer number) this is used in netpd, though i am not sure if it makes sense to have it as a standard. if you think, that it makes sense to have a version tag at all, it'd be cool, if we could define it that way to define a version. where can i get info about [pd META] ? roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On 19/06/2007, at 18.48, Roman Haefeli wrote: i forgot to mention, my and syntax' abstractions use a version tag of the format: [version x.x.x( (where x can be any integer number) this is used in netpd, though i am not sure if it makes sense to have it as a standard. if you think, that it makes sense to have a version tag at all, it'd be cool, if we could define it that way to define a version. Version numbers i think is crucial. It is simply a dread when folks share there nice code and one don't have a simple system (version numbers) to keep track of what is what and what is newer. By all means, please! The x.x.x-system might be nice. How do you use it? Keep the first x=0 at all times as no code gets to version 1; bumb the second x when new features are added; bumb the last x when bugs are corrected? - Such info one how the version numbers makes sense is nice to add in a README, i think. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On 19/06/2007, at 1.06, Roman Haefeli wrote: On Tue, 2007-06-19 at 00:47 +0200, Steffen wrote: On 18/06/2007, at 23.21, Roman Haefeli wrote: one question still remains: how is it organized? If it is of any interest i've already voided my opinion, cf. http://lists.puredata.info/pipermail/pd-list/2007-06/051122.html absolutely. thanks for bringing this up again. i agree with you, though great. who does define the goals? I think you (pl.) are defining the goals and form of it in this email correspondence. It goes quite well. When you consider it dense, add it up in a README. Maybe even make a wiki page for it in http:// puredata.info/community/projects/ holding the README and pointing to the files in the lib, but keeping stuff in _a_ cvs might be nice over time. maybe you have already an idea about how the goals could look like? I have ideas and expectations to this project. I think it is a very nice idea that i've hoped to happen. The idea of having a shared lib with focus on (mid-level) dsp abstractions or sound modules i think might make it huge, as in lots of folks might use and like it. and add to it. Id like to see the orchestra lib too, but it might be nice as a separate project as it's easy to specify what it should consist of (ie. orchestra voices). And as it might make sense to have another form (where form means interface to the objects in the lib) then what it going to be the form in this lib. But i don't have any abs to share atm, and don't have much time to write down my ideas. Damn studies. Question. Will all the object be like: input: control data output: signal/audio, or will the also be (audio manipulators) objects like: input: signal/audio output: singal/audio? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
Hallo, Steffen hat gesagt: // Steffen wrote: Version numbers i think is crucial. It is simply a dread when folks share there nice code and one don't have a simple system (version numbers) to keep track of what is what and what is newer. By all means, please! I don't think it's necessary on CVS or Subversion, as you have the date of last change. I wouldn't want to make this an obligatory field. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On 19/06/2007, at 19.52, Frank Barknecht wrote: Steffen hat gesagt: // Steffen wrote: Version numbers i think is crucial. It is simply a dread when folks share there nice code and one don't have a simple system (version numbers) to keep track of what is what and what is newer. By all means, please! I don't think it's necessary on CVS or Subversion, as you have the date of last change. That is, of cause, true, that with in a versioning system there is a value that represents the version. The problem is, when it leaves the versioning system. I wouldn't want to make this an obligatory field. I don't think i would want to make anything obligatory. And I still use nice version-less code as it it better then bad code with version numbers or no code at all. I was just begging for a thing that i desire. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On Tue, 2007-06-19 at 19:33 +0200, Steffen wrote: The x.x.x-system might be nice. How do you use it? Keep the first x=0 at all times as no code gets to version 1; bumb the second x when new features are added; bumb the last x when bugs are corrected? - yo, that is how i use them. but the main reason, why netpd uses it, is a purely technical one: patches and abstractions are shared between netpd clients. in order to make sure, that changes made to a patch or abstraction get to the other netpd clients as well, this versioning system was introduced. when loading a patch with creator, the version is checked by creator and compared with the version of the same patch on the other clients. if the patch to be opened has a higher version number than the on the other clients, the patch is uploaded instead of only opened, so that the patch on the other clients is overwritten. Such info one how the version numbers makes sense is nice to add in a README, i think. hm, since - as frank stated - a version number is not essential, i'd say, it wouldn't do it into the readme. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On Tue, 2007-06-19 at 19:44 +0200, Steffen wrote: who does define the goals? I think you (pl.) are defining the goals and form of it in this email correspondence. It goes quite well. When you consider it dense, add it up in a README. Maybe even make a wiki page for it in http:// puredata.info/community/projects/ holding the README and pointing to the files in the lib, but keeping stuff in _a_ cvs might be nice over time. a wiki-page for streamlining the idea and a little howto-guide (with the stuff we already discussed) would be nice, though i don't know how to create the page, respectively who as write acces to it. Question. Will all the object be like: input: control data output: signal/audio, or will the also be (audio manipulators) objects like: input: signal/audio output: singal/audio? i'd say both, any module that either generates or manipulates audio signals. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On 19/06/2007, at 21.55, Roman Haefeli wrote: a wiki-page for streamlining the idea and a little howto-guide (with the stuff we already discussed) would be nice, though i don't know how to create the page, respectively who as write acces to it. I think it's a matter for proposing it to he pdweb list. Alternatively it could go into a README. Thats what they are for, i think. Question. Will all the object be like: input: control data output: signal/audio, or will the also be (audio manipulators) objects like: input: signal/audio output: singal/audio? i'd say both, any module that either generates or manipulates audio signals. Cool. Then that should be added too, i think. As i see it now, based on the discussion, the lazy-consensus principle, the fact that no one objected against that all abstractions in the lib should have a help file, a README could sound: - This lib, tilde, is focused on dps'ish abstractions that either generates or manipulates audio signals. To add to the lib either check it into _the_ cvs if you have access or ask someone that have access to check it in for you. All abstractions in the lib need have a corresponding help file documenting the inlet(s) and outlet(s). In case your abstraction have dependencies document it somewhere. In case the dependencies are not available anywhere and are in them self abstraction (ie. not externals) add them to a subfolder to not pollute the namespace of the lib. - eh? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On Tue, 2007-06-19 at 17:11 +0200, Frank Barknecht wrote: Some other things: A tricky issue may be abstractions that use other custom abstractions. I think, a subdirectory for these sub-abstractions would be good to have, so that the namespace doesn't get polluted. personally, i don't support this idea. i believe, that there will be far too less abstraction for caring about namespace pollution. but my main argument is, that it is not always easy to decide, whether a certain abs is of general use (and deserves to be in the main-folder) or if it should go to a subfolder. why don't we put just everything into the main-folder, as long it has a help-patch? roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
Hallo, Steffen hat gesagt: // Steffen wrote: On 19/06/2007, at 21.55, Roman Haefeli wrote: a wiki-page for streamlining the idea and a little howto-guide (with the stuff we already discussed) would be nice, though i don't know how to create the page, respectively who as write acces to it. I think it's a matter for proposing it to he pdweb list. Alternatively it could go into a README. Thats what they are for, i think. IIRC the wiki generally can be edited by anyone with an account. Adding pages was a bit tricky, as there is (was?) a bug that you first had to create a PageLink on some other page, then follow that link to the non-existing page which would then be editable. I'll try to setup a Topic similar to http://puredata.info/community/patches etc. that automatically will collect all patches tagged with a specific keyword like tilde-lib or so. How to tag is described here: http://puredata.info/docs/tutorials/HowToContribute/ Question. Will all the object be like: input: control data output: signal/audio, or will the also be (audio manipulators) objects like: input: signal/audio output: singal/audio? i'd say both, any module that either generates or manipulates audio signals. Cool. Then that should be added too, i think. As i see it now, based on the discussion, the lazy-consensus principle, the fact that no one objected against that all abstractions in the lib should have a help file, a README could sound: - This lib, tilde, is focused on dps'ish abstractions that either generates or manipulates audio signals. To add to the lib either check it into _the_ cvs if you have access or ask someone that have access to check it in for you. All abstractions in the lib need have a corresponding help file documenting the inlet(s) and outlet(s). In case your abstraction have dependencies document it somewhere. In case the dependencies are not available anywhere and are in them self abstraction (ie. not externals) add them to a subfolder to not pollute the namespace of the lib. - eh? Perfect!! Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
I am curious, has anyone ever vandalized the netpd patches during a jam? ~Kyle On 6/19/07, Roman Haefeli [EMAIL PROTECTED] wrote: On Tue, 2007-06-19 at 19:33 +0200, Steffen wrote: The x.x.x-system might be nice. How do you use it? Keep the first x=0 at all times as no code gets to version 1; bumb the second x when new features are added; bumb the last x when bugs are corrected? - yo, that is how i use them. but the main reason, why netpd uses it, is a purely technical one: patches and abstractions are shared between netpd clients. in order to make sure, that changes made to a patch or abstraction get to the other netpd clients as well, this versioning system was introduced. when loading a patch with creator, the version is checked by creator and compared with the version of the same patch on the other clients. if the patch to be opened has a higher version number than the on the other clients, the patch is uploaded instead of only opened, so that the patch on the other clients is overwritten. Such info one how the version numbers makes sense is nice to add in a README, i think. hm, since - as frank stated - a version number is not essential, i'd say, it wouldn't do it into the readme. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
Another interesting approach is that taken by pdmtl, which uses a namespace-type separation of objects based upon their type and use. IIRC, it is not in Pd-extended yet either... ~Kyle On 6/19/07, Steffen [EMAIL PROTECTED] wrote: On 19/06/2007, at 21.55, Roman Haefeli wrote: a wiki-page for streamlining the idea and a little howto-guide (with the stuff we already discussed) would be nice, though i don't know how to create the page, respectively who as write acces to it. I think it's a matter for proposing it to he pdweb list. Alternatively it could go into a README. Thats what they are for, i think. Question. Will all the object be like: input: control data output: signal/audio, or will the also be (audio manipulators) objects like: input: signal/audio output: singal/audio? i'd say both, any module that either generates or manipulates audio signals. Cool. Then that should be added too, i think. As i see it now, based on the discussion, the lazy-consensus principle, the fact that no one objected against that all abstractions in the lib should have a help file, a README could sound: - This lib, tilde, is focused on dps'ish abstractions that either generates or manipulates audio signals. To add to the lib either check it into _the_ cvs if you have access or ask someone that have access to check it in for you. All abstractions in the lib need have a corresponding help file documenting the inlet(s) and outlet(s). In case your abstraction have dependencies document it somewhere. In case the dependencies are not available anywhere and are in them self abstraction (ie. not externals) add them to a subfolder to not pollute the namespace of the lib. - eh? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
Hello, Kyle Klipowicz a écrit : I am curious, has anyone ever vandalized the netpd patches during a jam? It's true that things might be a lot more complicated if net-pd users starts to build net-pd objects with using pd-extended distro, and jam with people that are using net-pd distro. I guess you start to see how it might be important to have a kind of coordinator for the patch sharing. Best, Patko. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
Here is a link to the pdmtl list of files. It has quite a few objects, and a lot of dsp ones too. I am all for adopting this framework, since it is already semi-established with users. http://wiki.dataflow.ws/PdMtlAbstractions/Contents Let's face it, it's difficult to find objects through the sorting of author libs right now, since a given author may have a bunch of different abstractions or externals in a sort of hodge-podged bundle. Not all authors do this of course, since we now have separate cvs entries for things like list-abs, etc. Taking from the pdmtl aesthetic would be the next step. ~Kyle On 6/19/07, Kyle Klipowicz [EMAIL PROTECTED] wrote: Another interesting approach is that taken by pdmtl, which uses a namespace-type separation of objects based upon their type and use. IIRC, it is not in Pd-extended yet either... ~Kyle On 6/19/07, Steffen [EMAIL PROTECTED] wrote: On 19/06/2007, at 21.55, Roman Haefeli wrote: a wiki-page for streamlining the idea and a little howto-guide (with the stuff we already discussed) would be nice, though i don't know how to create the page, respectively who as write acces to it. I think it's a matter for proposing it to he pdweb list. Alternatively it could go into a README. Thats what they are for, i think. Question. Will all the object be like: input: control data output: signal/audio, or will the also be (audio manipulators) objects like: input: signal/audio output: singal/audio? i'd say both, any module that either generates or manipulates audio signals. Cool. Then that should be added too, i think. As i see it now, based on the discussion, the lazy-consensus principle, the fact that no one objected against that all abstractions in the lib should have a help file, a README could sound: - This lib, tilde, is focused on dps'ish abstractions that either generates or manipulates audio signals. To add to the lib either check it into _the_ cvs if you have access or ask someone that have access to check it in for you. All abstractions in the lib need have a corresponding help file documenting the inlet(s) and outlet(s). In case your abstraction have dependencies document it somewhere. In case the dependencies are not available anywhere and are in them self abstraction (ie. not externals) add them to a subfolder to not pollute the namespace of the lib. - eh? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- - - - -- http://perhapsidid.wordpress.com -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [dsplib]: how should it be maintained?
hello everyone one question still remains: how is it organized? will some mercyful person voluntarly collect the dsp abs and check it in into cvs? or shall we give cvs write access to every interested author? personally, i'd like to concentrate on netpd, rather than maintaining this project. but if we decide to give cvs write acces to everyone interested, i'd check in my stuff, of course. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On 18/06/2007, at 23.21, Roman Haefeli wrote: one question still remains: how is it organized? If it is of any interest i've already voided my opinion, cf. http://lists.puredata.info/pipermail/pd-list/2007-06/051122.html ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On Tue, 2007-06-19 at 00:47 +0200, Steffen wrote: On 18/06/2007, at 23.21, Roman Haefeli wrote: one question still remains: how is it organized? If it is of any interest i've already voided my opinion, cf. http://lists.puredata.info/pipermail/pd-list/2007-06/051122.html absolutely. thanks for bringing this up again. i agree with you, though who does define the goals? maybe you have already an idea about how the goals could look like? roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [dsplib]: how should it be maintained?
On Mon, 2007-06-18 at 23:34 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: one question still remains: how is it organized? will some mercyful person voluntarly collect the dsp abs and check it in into cvs? or shall we give cvs write access to every interested author? I'd rather not give anyone write permissions, as we're already are quite a huge number of developers. I would give permissions to you, however, also for netpd. ;) I'd volunteer to check in the dsp abstractions. May we could collect them on puredata.info first. Then from time to time I or someone else would check in the latest versions into CVS. yo, i put my stuff on: http://puredata.info/Members/rdz/ roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
