I think this has been asked before, but why isn't sssad included in pd-extended? It's stable and I've been using it for quite some time and I know its getting plenty of use in rjlib.
PS: Thanks 12848492048 times over Frank.
Dan Wilcox danomatika.com robotcowboy.com
The short answer is because no one has done the work. The long answer
involves me being overwhelmed with maintenance work and am now instead
reshaping how libraries get distributed. These days, I'm spending
more time to make it easier for people to make and distribute their
own libraries, and then to make it easy to install and use libraries.
But for those who are interested in taking on the addition and
maintenance of libraries in Pd-extended, I've started to write up some
notes of my own process for people to guide their libraries thru if
they are interested.
http://puredata.info/docs/developer/GettingIntoPdextended
.hc
On Sep 18, 2010, at 6:03 AM, Dan Wilcox wrote:
I think this has been asked before, but why isn't sssad included in
pd-extended? It's stable and I've been using it for quite some time
and I know its getting plenty of use in rjlib.PS: Thanks 12848492048 times over Frank.
Dan Wilcox danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
¡El pueblo unido jamás será vencido!
Hi,
On Sat, Sep 18, 2010 at 06:03:34AM -0400, Dan Wilcox wrote:
I think this has been asked before, but why isn't sssad included in pd-extended? It's stable and I've been using it for quite some time and I know its getting plenty of use in rjlib.
Apart from being packaged as its own Debian package (which is a new requirement) it fulfills all requirements for pd-x-inclusion listed on the puredata.info page.
Maybe the question should better be: Why was sssad removed from pd-extended after 0.41 and still is? My inquiries regarding the reasons like http://www.mail-archive.com/pd-list@iem.at/msg35153.html haven't been answered. I can live with that, it's well known that I don't use pd-x (things like the sssad-issue are only reinforcing this decision), but I know, that many people would love to use sssad or already do but hate it when they have to install a single-object library manually into their pd-extended install.
PS: Thanks 12848492048 times over Frank.
12848492048 welcomes! :)
Ciao
Frank
On Sep 21, 2010, at 6:47 AM, Frank Barknecht wrote:
On Sat, Sep 18, 2010 at 06:03:34AM -0400, Dan Wilcox wrote:
I think this has been asked before, but why isn't sssad included in pd-extended? It's stable and I've been using it for quite some time and I know its getting plenty of use in rjlib.
Apart from being packaged as its own Debian package (which is a new requirement) it fulfills all requirements for pd-x-inclusion listed on the puredata.info page.
Maybe the question should better be: Why was sssad removed from pd-extended after 0.41 and still is?
I think it's the maintenance issue. I can understand the need to flush everything out, then start adding the solid, maintainable externals back in ... although I think sssad is both solid and maintainable already.
but I know, that many people would love to use sssad or already do but hate it when they have to install a single-object library manually into their pd-extended install.
Ja, that's why I distribute sssad with my lib. It would be nicer to have it as a pd-ext standard IMO, so those of us who use it in abstractions can stop packaging it.
Are there any objections to me following Hans' guide and adding it? What about the Debian packaging issue? I suppose I can do that too if needed ... as well as volunteer to be the maintainer. I want to push my patches into pd-ext soon anyway.
Dan Wilcox danomatika.com robotcowboy.com
On Sep 21, 2010, at 1:02 PM, Dan Wilcox wrote:
On Sep 21, 2010, at 6:47 AM, Frank Barknecht wrote:
On Sat, Sep 18, 2010 at 06:03:34AM -0400, Dan Wilcox wrote:
I think this has been asked before, but why isn't sssad included in pd-extended? It's stable and I've been using it for quite some time and I know its getting plenty of use in rjlib.
Apart from being packaged as its own Debian package (which is a new requirement) it fulfills all requirements for pd-x-inclusion listed
on the puredata.info page.Maybe the question should better be: Why was sssad removed from pd-extended after 0.41 and still is?
I think it's the maintenance issue. I can understand the need to
flush everything out, then start adding the solid, maintainable
externals back in ... although I think sssad is both solid and
maintainable already.but I know, that many people would love to use sssad or already do
but hate it when they have to install a single-object library manually
into their pd-extended install.Ja, that's why I distribute sssad with my lib. It would be nicer to
have it as a pd-ext standard IMO, so those of us who use it in
abstractions can stop packaging it.Are there any objections to me following Hans' guide and adding it?
What about the Debian packaging issue? I suppose I can do that too
if needed ... as well as volunteer to be the maintainer. I want to
push my patches into pd-ext soon anyway.
From what I rememeber, it was excluded because it was non-functional
the way it was included. There is a bug that prevents the libdir
packaging working when the folder has the same name as the abstraction
in it, i.e. sssad/sssad.pd. T
This works with binary externals.
As for alternate ways of including things besides libdirs, there are
lots of kludges currently in Pd-extended. I've been spending a lot of
my time maintaining them. I'm working on reducing maintenance time so
I can actually spend time coding new things. So far, only a couple
people have a track record of actually maintaining code in Pd-extended
without me needing to get involved (Martin Peach, Matju, Roman,
IOhannes, I'm probably missing someone).
So I think the way forward is to make it easy for people to distribute
their own libraries on their own, and make them really easy to install
and use. Pd-extended 0.42.5 and Pd-vanilla 0.43 have big improvements
in that regard, so people should try that path first (i.e. package as
libdir, make the libdir usable when dropped into the standard user
install paths in the FAQ, etc.)
.hc
"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.
On Sep 21, 2010, at 2:19 PM, Hans-Christoph Steiner wrote:
From what I rememeber, it was excluded because it was non-functional the way it was included. There is a bug that prevents the libdir packaging working when the folder has the same name as the abstraction in it, i.e. sssad/sssad.pd. T This works with binary externals.
As for alternate ways of including things besides libdirs, there are lots of kludges currently in Pd-extended. I've been spending a lot of my time maintaining them. I'm working on reducing maintenance time so I can actually spend time coding new things. So far, only a couple people have a track record of actually maintaining code in Pd-extended without me needing to get involved (Martin Peach, Matju, Roman, IOhannes, I'm probably missing someone).
So I think the way forward is to make it easy for people to distribute their own libraries on their own, and make them really easy to install and use. Pd-extended 0.42.5 and Pd-vanilla 0.43 have big improvements in that regard, so people should try that path first (i.e. package as libdir, make the libdir usable when dropped into the standard user install paths in the FAQ, etc.)
Ok, so the emphasis will be on less included libs within pd-ext in the future and more on the lib framework making externals easy to install? I think we mainly need a sort of "externals" portal on the website where everyone registers libs so its a one-stop shop for picking your object poison. This makes more sense then an every growing blob within pd-extended.
Dan Wilcox danomatika.com robotcowboy.com
On Sep 21, 2010, at 2:37 PM, Dan Wilcox wrote:
On Sep 21, 2010, at 2:19 PM, Hans-Christoph Steiner wrote:
From what I rememeber, it was excluded because it was non- functional the way it was included. There is a bug that prevents
the libdir packaging working when the folder has the same name as
the abstraction in it, i.e. sssad/sssad.pd. T This works with binary externals.As for alternate ways of including things besides libdirs, there
are lots of kludges currently in Pd-extended. I've been spending a
lot of my time maintaining them. I'm working on reducing
maintenance time so I can actually spend time coding new things.
So far, only a couple people have a track record of actually
maintaining code in Pd-extended without me needing to get involved
(Martin Peach, Matju, Roman, IOhannes, I'm probably missing someone).So I think the way forward is to make it easy for people to
distribute their own libraries on their own, and make them really
easy to install and use. Pd-extended 0.42.5 and Pd-vanilla 0.43
have big improvements in that regard, so people should try that
path first (i.e. package as libdir, make the libdir usable when
dropped into the standard user install paths in the FAQ, etc.)Ok, so the emphasis will be on less included libs within pd-ext in
the future and more on the lib framework making externals easy to
install? I think we mainly need a sort of "externals" portal on the
website where everyone registers libs so its a one-stop shop for
picking your object poison. This makes more sense then an every
growing blob within pd-extended.
If someone truly wants to take on maintaining more libs in Pd-
extended, that is ok by me. I really don't want people to add stuff
to Pd-extended then disappear leaving me to deal with it, that's
mostly what's happened.
As for a place for libs, IOhannes set this up a while ago, I've
started adding things to it, I think it works well as a place for
people to release their libs, GUI plugins, etc. I think we should
switch puredata.info/downloads to this page once we get things all
figured out.
http://puredata.info/community/projects/software/
.hc
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
On Tue, 21 Sep 2010, Hans-Christoph Steiner wrote:
As for alternate ways of including things besides libdirs, there are lots of kludges currently in Pd-extended. I've been spending a lot of my time maintaining them. I'm working on reducing maintenance time so I can actually spend time coding new things. So far, only a couple people have a track record of actually maintaining code in Pd-extended without me needing to get involved (Martin Peach, Matju, Roman, IOhannes, I'm probably missing someone).
I don't have any externals in pd-extended, nor in SourceForge.
Which code are you talking about ?
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Sep 21, 2010, at 6:43 PM, Mathieu Bouchard wrote:
On Tue, 21 Sep 2010, Hans-Christoph Steiner wrote:
As for alternate ways of including things besides libdirs, there
are lots of kludges currently in Pd-extended. I've been spending a
lot of my time maintaining them. I'm working on reducing
maintenance time so I can actually spend time coding new things.
So far, only a couple people have a track record of actually
maintaining code in Pd-extended without me needing to get involved
(Martin Peach, Matju, Roman, IOhannes, I'm probably missing someone).I don't have any externals in pd-extended, nor in SourceForge.
Which code are you talking about ?
What I mean is that you have gotten gridflow to work something like a
libdir without me having to fix it. Personally I'd like to see it
more like a libdir.
.hc
I hate it when they say, "He gave his life for his country." Nobody
gives their life for anything. We steal the lives of these kids. -
Admiral Gene LeRocque
-
Dan Wilcox -
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard