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
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.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
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
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:
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
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__
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
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.
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__
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.
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
I am curious, has anyone ever vandalized the netpd patches during a jam?
~Kyle
On 6/19/07, Roman Haefeli reduzierer@yahoo.de 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
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.
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
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
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
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
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
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
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
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"?
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
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?
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__
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 stffn@dibidut.dk 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
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 kyleklip@gmail.com 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 stffn@dibidut.dk 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
--
---- -----
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.
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__
that reminds me of a question i wanted to ask for a long time.
On Jun 20, 2007, at 10:32 AM, Frank Barknecht wrote:
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.
sometimes people send patches to pd-list without license comment.
the question is: can i use the patches and publish it again under gnu/lgpl ?
unfortunately i don't remember all sources. after seeing movie from google/talks, which Kyle posted, i want to mention all the authors in a central place and not in the patch itself. maybe in readme.txt
what do you think?
Andy, Frank, Matt (and all i forgot right now): is it ok with you when i use some of your patches and mention: which patches i use and where they are in a list in readme.txt and not in the patch itself?
i want respect all authors and respect their wish.
i have used Franks list-abs a lot but i can't use it as abstraction in netpd since 1) list-abs is no dependency of plain netpd. 2) list-abs of corse come without version tags, then they would be treated as if they had a [version 0.0.0( tag. but if a bug gets fixed this abstraction wouldn't get updated in netpd. don't see an other way than adapt it and use it in a subpatch.
regards
Enrique
well, i'm about to share a synth that takes lots of stuff from different peoples' works...and i have tried to credit them where i could, but sometimes it's hard to remember who made what patch.
and i was thinking about what to do about crediting others..
and i came to these conclusions: credit when possible, but if you forget someone don't worry too much - they'll get in touch if they are worried. most important is to share your works.
Hallo, Enrique Erne hat gesagt: // Enrique Erne wrote:
sometimes people send patches to pd-list without license comment.
the question is: can i use the patches and publish it again under gnu/lgpl ?
Hm, GPL already is a quite specific license, which, although I like it, might impose more restrictions than the original author intended. For the patches I post to the list I assmue a public domain license/no license. Putting the patches themselves under GPL would be a restriction of thise license. But of course you can bundle them with other GPL licenses and licence the whole package as GPL.
Of course sometimes I post abstractions from libraries that have a different license. [list]-abs for example has a Pd-style license.
i have used Franks list-abs a lot but i can't use it as abstraction in netpd since 1) list-abs is no dependency of plain netpd. 2) list-abs of corse come without version tags, then they would be treated as if they had a [version 0.0.0( tag. but if a bug gets fixed this abstraction wouldn't get updated in netpd. don't see an other way than adapt it and use it in a subpatch.
I cannot really help with that. The [list]-abs won't get version numbers, as there may be many different formats of numbers showing up. Of course you could bundle [list]-abs with netpd as well as a requirement.
But then, some list-abs are quite simple/short, so putting them into subpatches is a valid approach as well.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Wed, 2007-06-20 at 12:53 +0200, Enrique Erne wrote:
i have used Franks list-abs a lot but i can't use it as abstraction in netpd since 1) list-abs is no dependency of plain netpd. 2) list-abs of corse come without version tags, then they would be treated as if they had a [version 0.0.0( tag. but if a bug gets fixed this abstraction wouldn't get updated in netpd. don't see an other way than adapt it and use it in a subpatch.
you still can use them in netpd, but you need to 'port' them, which unfortunately introduces some additional work (basically adding version-tags). since netpd can handle recursive abslist, i thought about creating a dummy abstraction 'list-abs', that just contains an abslist with all list-abs in itself. then netpd-patch-develors would just have to mention 'list-abs' in abslist of the patch. though, i didn't find time to do that yet, and i am not so sure about if this is a good thing to do. whenever a change to list-abs is made, this change needs to be ported to netpd's list-abs. otoh, anyone could do that job at anytime withouth getting conflicts, as long the version numbers are handled with care.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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.
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
-
Enrique Erne -
Frank Barknecht -
hard off -
Kyle Klipowicz -
Patco -
patrice colet
-
Roman Haefeli -
Steffen