Hello, I'm opening a new thread about the new direction of discussion with a proper subject title. Perhaps this will call the attention of other readers.
I particularly think this is of major interest to everyone. We're discussing new ways of using the libraries in Pd Extended into Pd Vanilla, and even a way to bring some of the Pd-extended UI changes into vanilla.
Something Miller brought up in the thread was "*Just FYI…. Joe Deken of newblankets.org http://newblankets.org/ is considering making a repository of external objects compatible with Pd vanilla. I think almost all the* *objects in Pd extended will work with vanilla (and if I find out what specific changes vanilla would need to allow the others, I'd be happy to try to provide them). It seems like maintaining compiled versions of the **libs is an easier thing to do than maintaining all of Pd Extended*."
So, anyone else care to share their two cents?
cheers
2014-12-17 1:05 GMT-02:00 Jonathan Wilkes via Pd-list pd-list@lists.iem.at :
Well, you can peruse the tracker's open patches to get a sense of whether you can (or if it's worth your time to try). Keep in mind the Pd-l2ork gui prefs code started out as a patch specifically written as a clean, small patch to get into Vanilla/Extended.
-Jonathan
On Tuesday, December 16, 2014 6:04 PM, Dan Wilcox danomatika@gmail.com wrote:
Sorry, I didn;t mean to sound like I'm griping. The nature of the question was more "if we apply clean, small patches to vanilla, could we get some of Han's updates in so they aren't lost to non Pd-l2ork users". I'm in the middle of writing my thesis right now, but getting into real Pd development again is on my list when I'm finally done with it.
On Tue, Dec 16, 2014 at 5:59 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
On 12/16/2014 03:12 PM, Dan Wilcox wrote:
I like how I explicitly asked to not hear that "Pd-l2ork has that" and yet that's the response I got. I already knew this anyway from the sample screenshots you were posting when you were implementing it. (Looks great BTW)
Yeah, I know, it was 100% willful snark on my part. It's kind of like you were asking, "Is there a way to do X, while satisfying my irrational desire to ignore a working solution by someone who likely already did X?"
Anyway, did you look at the code? It's done in tcl/tk, and it does not depend on tkpath. So if you don't want to duplicate all the work I already did, you can fairly easily port that back to Pd Vanilla. There might be a few API differences in accessing the audio backend, but there are small and I don't mind helping make those changes.
Also, I specifically did everything in tcl/tk so that the patch would be as simple as possible. It shouldn't even require a recompile. Now, I haven't looked at Ivica's changes that added persistence. But all versions of Pd have the same prefs-saving code so that shouldn't be difficult, either.
Also, if you didn't know, why respond? :P
Because the answer to your question ultimately depends on whether what you come up with fits the unspoken yet stringent HIG standards imposed by Miller's Pd.
But that doesn't mean that code which does _exactly_ what you're asking about isn't relevant to your question.
-Jonathan
On 12/15/2014 06:21 PM, Dan Wilcox wrote:
If that does become a real scenario, I hope we can find a way to bring some of the Pd-extended UI changes into vanilla, such as the pixel perfect sizing across platforms, an option for the extended coloring (graytones) etc. Before anyone says “Pd-Lork has that”, I’m just wondering if it’s feasible to bring in some of the work Hans did after the gui cleanup which is already in vanilla.
In answer to your question: I don't know.
Having answered that...
Pd-l2ork has gui theme presets for Vanilla, Inverted Vanilla, Pd-extended, Commodore 64, Strongbad's Compy, and a few others. There's also an interface to make a custom theme-- I didn't make it persistent but I think Ivica added that ability.
-Jonathan
-- Dan Wilcox danomatika.com robotcowboy.com
-- Dan Wilcox danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Who is going to replace Hans? Here's an incomplete list of the responsibilities such a person would have:* all the technical responsibilities of maintaining releasing software (whether that software is a collection of libraries or a full distro of Pd, the work required is still comparable)* maintaining the abandoned libs that users still need* responding to requests from new developers in a timely manner* being a leader. For example, when someone asks a question whether doing X is feasible, you would give a clear and definitive answer based on where you think the project should go* being a diplomat. After someone has done the work you encouraged them to do and Miller says he wants to take another decade to think of a better solution, you have to find a compromise that doesn't discourage the development effort (and create yet another unmaintained lib or patch/plugin for Vanilla)* generally encouraging development efforts of developers with various styles of communication and expectations for the software* working with developers like me who have essentially given up on trying to get improvements into Pd Vanilla. (But I am happy to work with anyone willing to do all this work) -Jonathan
Hello, I don't know if Hans is replaceable and I didn't mean to start a thread about "replacing" him or even point to a new "extended"distro.
I just wanted to highlight what miller mentioned about people considering working on a repository of external objects compatible to vanilla, and how all extended libs should work on vanilla and that he was willing to help make'm work in it.
I, for one, think that's good enough to work as an "extended" replacement, while hans (or any other who'd replace him) carries on with pd-extended (or some new distro).
As far as library management and maintenance goes. In my opinion, maybe that shouldn't be a burden that someone has to carry alone. I don't believe Hans vouched for being the one responsible for maintaining that much libraries on his own. I believe he ended up doing so because the original developers just didn't care anymore and abandoned it...
I have to say that's a hell of a bummer. And that I've had some experiences trying to reach creators and maintainers about a bug on some extended object and got not much help of something like "yeah, I know about it but I don't have time to work on it".
I love the work Hans did with Pd extended, and still use it, but I'm critic on how many libraries and objects are badly maintained, with bugs and not that good documentation. There are also many redundanct objects. So can't say it's such a great package of externals...
I know there are a few libraries I can't live without. Like, from the top of my head there are: zexy, iemlib, cyclone... I'd be kinda done with these few libraries.
In the scenario context we're discussing - of a repository of working libraries - if whoever made a library that was on the repository and, for some reason, it stopped working, I guess the creator should care to maintain it. but if he doesn't, if it's open source and everything, maybe someone else who cares would care to step in and deal with it.
But I have the idea that if a library is working fine as an external in vanilla, it should normally keep working as such. And Miller is here waving . And well, if it doesn't and nobody cares. Then it is crossed out of the repository. Simple as that...
So, it's a whole different paradigm. It's not about building and releasing a new distro. It's not about telling Miller what he should do with Vanilla. And it should be pretty simple as I see it. Moreover, I could manifest the opinion that that's the easy way and how it should be - a list of plugins, nicely organised somewhere, for people to download and use it.
And no need for that much diplomacy. I think it should be open and free. If people make some libraries and wanna to put it on the repository, just let'em do it.
Well, that's my two cents
Cheers
2014-12-17 18:08 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:
Who is going to replace Hans?
Here's an incomplete list of the responsibilities such a person would have:
- all the technical responsibilities of maintaining releasing software
(whether that software is a collection of libraries or a full distro of Pd, the work required is still comparable)
- maintaining the abandoned libs that users still need
- responding to requests from new developers in a timely manner
- being a leader. For example, when someone asks a question whether doing
X is feasible, you would give a clear and definitive answer based on where you think the project should go
- being a diplomat. After someone has done the work you encouraged them
to do and Miller says he wants to take another decade to think of a better solution, you have to find a compromise that doesn't discourage the development effort (and create yet another unmaintained lib or patch/plugin for Vanilla)
- generally encouraging development efforts of developers with various
styles of communication and expectations for the software
- working with developers like me who have essentially given up on trying
to get improvements into Pd Vanilla. (But I am happy to work with anyone willing to do all this work)
-Jonathan
I agree. It became too much for one person and this could be a more reasonable way to move forward.
I say “divide and conquer”. We all recognize and applaud the work that Hans has done, but at this point, I feel the centralized external repository is the main stopping point every time someone has to ask who is maintaining what and if they can have svn access to provide a patch.
I think most externals have managed to weed themselves out over time. You basically listed the most stable externals (iem ones). I’d add mrpeach and cyclone to that list. A lot of the others have gotten pretty hairy and probably don’t need to be kept active at this point.
We could start by moving popular externals off of the sourceforge svn and into separate Github repos, each with a maintainer. Getting them onto Github alone would be worth it in that it’s plainly a lot easier to collaborate. People would be then free to support the externals they want and the strongest ones would continue on. This could be done through a Pure Data group, like the “pd-projects” group. Old, unused externals could be kept in the svn until someone wants to “promote” them and volunteers to maintain them.
This model has worked very well for OpenFrameworks. In OF, we've standardized around an “addon” external source code/library format and naming convention and there are now quite alot of useful addons in the wild. There’s even a website which indexes them based on metadata off of Github: http://ofxaddons.com http://ofxaddons.com/. Hans has already put together an external template and makefiles and I’m sure we could build similar indexing site for pd-externals (or I can ask for the ofxaddons.com source code).
It would be great to have each external or related groups like iemlib working as a separate download/clone that just builds out of the box. That would be the first step toward integration with build servers to provide binaries. Unlike OF which is distributed as source code, we *have* to provide binaries which is one of the hardest parts of maintaining software. It’s alot easier if the work is split up so the Linux people can package the external (lie IOhannes and Debian), then OSX people can build new versions, and the Windows people can build new versions now and then. A cherry on top would be making sure the makefiles work *really* well and there is good documentation on how to use them so beginners are more likely to pitch in and try. This model has worked well for OF and Max externals have been distributed as source code/binaries for years now.
I think this makes sense, really. It removes the burden of having to maintain a mega release like Pd-extended and splits up the external maintenance. It does, however, require end users to manually download the externals they need, but that’s not a huge deal if we make it as easy as possible.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 17, 2014, at 9:33 PM, Alexandre Torres Porres porres@gmail.com wrote:
Hello, I don't know if Hans is replaceable and I didn't mean to start a thread about "replacing" him or even point to a new "extended"distro.
I just wanted to highlight what miller mentioned about people considering working on a repository of external objects compatible to vanilla, and how all extended libs should work on vanilla and that he was willing to help make'm work in it.
I, for one, think that's good enough to work as an "extended" replacement, while hans (or any other who'd replace him) carries on with pd-extended (or some new distro).
As far as library management and maintenance goes. In my opinion, maybe that shouldn't be a burden that someone has to carry alone. I don't believe Hans vouched for being the one responsible for maintaining that much libraries on his own. I believe he ended up doing so because the original developers just didn't care anymore and abandoned it...
I have to say that's a hell of a bummer. And that I've had some experiences trying to reach creators and maintainers about a bug on some extended object and got not much help of something like "yeah, I know about it but I don't have time to work on it".
I love the work Hans did with Pd extended, and still use it, but I'm critic on how many libraries and objects are badly maintained, with bugs and not that good documentation. There are also many redundanct objects. So can't say it's such a great package of externals...
I know there are a few libraries I can't live without. Like, from the top of my head there are: zexy, iemlib, cyclone... I'd be kinda done with these few libraries.
In the scenario context we're discussing - of a repository of working libraries - if whoever made a library that was on the repository and, for some reason, it stopped working, I guess the creator should care to maintain it. but if he doesn't, if it's open source and everything, maybe someone else who cares would care to step in and deal with it.
But I have the idea that if a library is working fine as an external in vanilla, it should normally keep working as such. And Miller is here waving . And well, if it doesn't and nobody cares. Then it is crossed out of the repository. Simple as that...
So, it's a whole different paradigm. It's not about building and releasing a new distro. It's not about telling Miller what he should do with Vanilla. And it should be pretty simple as I see it. Moreover, I could manifest the opinion that that's the easy way and how it should be - a list of plugins, nicely organised somewhere, for people to download and use it.
And no need for that much diplomacy. I think it should be open and free. If people make some libraries and wanna to put it on the repository, just let'em do it.
Well, that's my two cents
Cheers
Hi all,
I guess the subject of the thread is misleading, perhaps we should be talking about an external repository rather than "extending" vanilla?
I'd certainly be interested in contributing my own externals.
best,
Jaime
On Dec 17, 2014, at 9:33 PM, Alexandre Torres Porres porres@gmail.com wrote:
Hello, I don't know if Hans is replaceable and I didn't mean to start a thread about "replacing" him or even point to a new "extended"distro.
I just wanted to highlight what miller mentioned about people considering working on a repository of external objects compatible to vanilla, and how all extended libs should work on vanilla and that he was willing to help make'm work in it.
I, for one, think that's good enough to work as an "extended" replacement, while hans (or any other who'd replace him) carries on with pd-extended (or some new distro).
As far as library management and maintenance goes. In my opinion, maybe that shouldn't be a burden that someone has to carry alone. I don't believe Hans vouched for being the one responsible for maintaining that much libraries on his own. I believe he ended up doing so because the original developers just didn't care anymore and abandoned it...
I have to say that's a hell of a bummer. And that I've had some experiences trying to reach creators and maintainers about a bug on some extended object and got not much help of something like "yeah, I know about it but I don't have time to work on it".
I love the work Hans did with Pd extended, and still use it, but I'm critic on how many libraries and objects are badly maintained, with bugs and not that good documentation. There are also many redundanct objects. So can't say it's such a great package of externals...
I know there are a few libraries I can't live without. Like, from the top of my head there are: zexy, iemlib, cyclone... I'd be kinda done with these few libraries.
In the scenario context we're discussing - of a repository of working libraries - if whoever made a library that was on the repository and, for some reason, it stopped working, I guess the creator should care to maintain it. but if he doesn't, if it's open source and everything, maybe someone else who cares would care to step in and deal with it.
But I have the idea that if a library is working fine as an external in vanilla, it should normally keep working as such. And Miller is here waving . And well, if it doesn't and nobody cares. Then it is crossed out of the repository. Simple as that...
So, it's a whole different paradigm. It's not about building and releasing a new distro. It's not about telling Miller what he should do with Vanilla. And it should be pretty simple as I see it. Moreover, I could manifest the opinion that that's the easy way and how it should be - a list of plugins, nicely organised somewhere, for people to download and use it.
And no need for that much diplomacy. I think it should be open and free. If people make some libraries and wanna to put it on the repository, just let'em do it.
Well, that's my two cents
Cheers
2014-12-17 18:08 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:
Who is going to replace Hans?
Here's an incomplete list of the responsibilities such a person would have:
- all the technical responsibilities of maintaining releasing software (whether that software is a collection of libraries or a full distro of Pd, the work required is still comparable)
- maintaining the abandoned libs that users still need
- responding to requests from new developers in a timely manner
- being a leader. For example, when someone asks a question whether doing X is feasible, you would give a clear and definitive answer based on where you think the project should go
- being a diplomat. After someone has done the work you encouraged them to do and Miller says he wants to take another decade to think of a better solution, you have to find a compromise that doesn't discourage the development effort (and create yet another unmaintained lib or patch/plugin for Vanilla)
- generally encouraging development efforts of developers with various styles of communication and expectations for the software
- working with developers like me who have essentially given up on trying to get improvements into Pd Vanilla. (But I am happy to work with anyone willing to do all this work)
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I’m saying we don’t need a single externals repository … that’s one of the main problems right now. You shouldn’t have to contribute your externals beyond making sure they are buildable with a standard makefile, host them somewhere where they can be downloaded, and (hopefully) provide binaries. I think that’s the first step and later, if we wanted, we could go about having an external build system grab each of them in turn into an autobuild. This splits up the maintenance and responsibility plus makes it *alot* easier for people to collaborate. It works *very* well for OpenFrameworks.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 17, 2014, at 10:11 PM, Jaime E Oliver jaime.oliver2@gmail.com wrote:
Hi all,
I guess the subject of the thread is misleading, perhaps we should be talking about an external repository rather than "extending" vanilla?
I'd certainly be interested in contributing my own externals.
best,
Jaime
On Dec 17, 2014, at 9:33 PM, Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> wrote:
Hello, I don't know if Hans is replaceable and I didn't mean to start a thread about "replacing" him or even point to a new "extended"distro.
I just wanted to highlight what miller mentioned about people considering working on a repository of external objects compatible to vanilla, and how all extended libs should work on vanilla and that he was willing to help make'm work in it.
I, for one, think that's good enough to work as an "extended" replacement, while hans (or any other who'd replace him) carries on with pd-extended (or some new distro).
As far as library management and maintenance goes. In my opinion, maybe that shouldn't be a burden that someone has to carry alone. I don't believe Hans vouched for being the one responsible for maintaining that much libraries on his own. I believe he ended up doing so because the original developers just didn't care anymore and abandoned it...
I have to say that's a hell of a bummer. And that I've had some experiences trying to reach creators and maintainers about a bug on some extended object and got not much help of something like "yeah, I know about it but I don't have time to work on it".
I love the work Hans did with Pd extended, and still use it, but I'm critic on how many libraries and objects are badly maintained, with bugs and not that good documentation. There are also many redundanct objects. So can't say it's such a great package of externals...
I know there are a few libraries I can't live without. Like, from the top of my head there are: zexy, iemlib, cyclone... I'd be kinda done with these few libraries.
In the scenario context we're discussing - of a repository of working libraries - if whoever made a library that was on the repository and, for some reason, it stopped working, I guess the creator should care to maintain it. but if he doesn't, if it's open source and everything, maybe someone else who cares would care to step in and deal with it.
But I have the idea that if a library is working fine as an external in vanilla, it should normally keep working as such. And Miller is here waving . And well, if it doesn't and nobody cares. Then it is crossed out of the repository. Simple as that...
So, it's a whole different paradigm. It's not about building and releasing a new distro. It's not about telling Miller what he should do with Vanilla. And it should be pretty simple as I see it. Moreover, I could manifest the opinion that that's the easy way and how it should be - a list of plugins, nicely organised somewhere, for people to download and use it.
And no need for that much diplomacy. I think it should be open and free. If people make some libraries and wanna to put it on the repository, just let'em do it.
Well, that's my two cents
Cheers
2014-12-17 18:08 GMT-02:00 Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com>:
Who is going to replace Hans?
Here's an incomplete list of the responsibilities such a person would have:
- all the technical responsibilities of maintaining releasing software (whether that software is a collection of libraries or a full distro of Pd, the work required is still comparable)
- maintaining the abandoned libs that users still need
- responding to requests from new developers in a timely manner
- being a leader. For example, when someone asks a question whether doing X is feasible, you would give a clear and definitive answer based on where you think the project should go
- being a diplomat. After someone has done the work you encouraged them to do and Miller says he wants to take another decade to think of a better solution, you have to find a compromise that doesn't discourage the development effort (and create yet another unmaintained lib or patch/plugin for Vanilla)
- generally encouraging development efforts of developers with various styles of communication and expectations for the software
- working with developers like me who have essentially given up on trying to get improvements into Pd Vanilla. (But I am happy to work with anyone willing to do all this work)
-Jonathan
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
(you email came in before I replied...)
But it all sounds good. Perhaps just having a list somewhere that links to these externals? I do think there is value to having specific links or lists that point to these binaries or sources. Similar perhaps to the one you mentioned: http://ofxaddons.com
Also, from your previous email:
Hans has already put together an external template and makefiles and I’m sure we could build similar indexing site for pd-externals (or I can ask for the ofxaddons.com source code).
Is this being maintained by someone? I don't think I am able to do it, but this is crucial to teach how to write or compile externals…
best,
J
On Dec 17, 2014, at 10:18 PM, Dan Wilcox danomatika@gmail.com wrote:
I’m saying we don’t need a single externals repository … that’s one of the main problems right now. You shouldn’t have to contribute your externals beyond making sure they are buildable with a standard makefile, host them somewhere where they can be downloaded, and (hopefully) provide binaries. I think that’s the first step and later, if we wanted, we could go about having an external build system grab each of them in turn into an autobuild. This splits up the maintenance and responsibility plus makes it *alot* easier for people to collaborate. It works *very* well for OpenFrameworks.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Dec 17, 2014, at 10:11 PM, Jaime E Oliver jaime.oliver2@gmail.com wrote:
Hi all,
I guess the subject of the thread is misleading, perhaps we should be talking about an external repository rather than "extending" vanilla?
I'd certainly be interested in contributing my own externals.
best,
Jaime
On Dec 17, 2014, at 9:33 PM, Alexandre Torres Porres porres@gmail.com wrote:
Hello, I don't know if Hans is replaceable and I didn't mean to start a thread about "replacing" him or even point to a new "extended"distro.
I just wanted to highlight what miller mentioned about people considering working on a repository of external objects compatible to vanilla, and how all extended libs should work on vanilla and that he was willing to help make'm work in it.
I, for one, think that's good enough to work as an "extended" replacement, while hans (or any other who'd replace him) carries on with pd-extended (or some new distro).
As far as library management and maintenance goes. In my opinion, maybe that shouldn't be a burden that someone has to carry alone. I don't believe Hans vouched for being the one responsible for maintaining that much libraries on his own. I believe he ended up doing so because the original developers just didn't care anymore and abandoned it...
I have to say that's a hell of a bummer. And that I've had some experiences trying to reach creators and maintainers about a bug on some extended object and got not much help of something like "yeah, I know about it but I don't have time to work on it".
I love the work Hans did with Pd extended, and still use it, but I'm critic on how many libraries and objects are badly maintained, with bugs and not that good documentation. There are also many redundanct objects. So can't say it's such a great package of externals...
I know there are a few libraries I can't live without. Like, from the top of my head there are: zexy, iemlib, cyclone... I'd be kinda done with these few libraries.
In the scenario context we're discussing - of a repository of working libraries - if whoever made a library that was on the repository and, for some reason, it stopped working, I guess the creator should care to maintain it. but if he doesn't, if it's open source and everything, maybe someone else who cares would care to step in and deal with it.
But I have the idea that if a library is working fine as an external in vanilla, it should normally keep working as such. And Miller is here waving . And well, if it doesn't and nobody cares. Then it is crossed out of the repository. Simple as that...
So, it's a whole different paradigm. It's not about building and releasing a new distro. It's not about telling Miller what he should do with Vanilla. And it should be pretty simple as I see it. Moreover, I could manifest the opinion that that's the easy way and how it should be - a list of plugins, nicely organised somewhere, for people to download and use it.
And no need for that much diplomacy. I think it should be open and free. If people make some libraries and wanna to put it on the repository, just let'em do it.
Well, that's my two cents
Cheers
2014-12-17 18:08 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:
Who is going to replace Hans?
Here's an incomplete list of the responsibilities such a person would have:
- all the technical responsibilities of maintaining releasing software (whether that software is a collection of libraries or a full distro of Pd, the work required is still comparable)
- maintaining the abandoned libs that users still need
- responding to requests from new developers in a timely manner
- being a leader. For example, when someone asks a question whether doing X is feasible, you would give a clear and definitive answer based on where you think the project should go
- being a diplomat. After someone has done the work you encouraged them to do and Miller says he wants to take another decade to think of a better solution, you have to find a compromise that doesn't discourage the development effort (and create yet another unmaintained lib or patch/plugin for Vanilla)
- generally encouraging development efforts of developers with various styles of communication and expectations for the software
- working with developers like me who have essentially given up on trying to get improvements into Pd Vanilla. (But I am happy to work with anyone willing to do all this work)
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
It can be maintained. If we have a “puredata” Github organization (I made one already :D), for example, there could be an external template with the makefiles, sample readme, folder structure, metadata, etc.
This is what we do with OpenFrameworks. There is an ofxAddonTemplate https://github.com/openframeworks/ofxAddonTemplate that is both documentation and a template when creating a new addon. We then provide makefiles and a ProjectGenerator app that work with this layout and, if the addon is in the right place, make it relatively easy to include the external sources and libs into your project. Now, pd externals wouldn’t require a project generator but would need a makefile that find the pd sources and builds against them and/or any other required libs. Again, we can borrow form the great OF makefiles in this regard.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 17, 2014, at 10:33 PM, Jaime E Oliver jaime.oliver2@gmail.com wrote:
Hans has already put together an external template and makefiles and I’m sure we could build similar indexing site for pd-externals (or I can ask for the ofxaddons.com http://ofxaddons.com/ source code).
Is this being maintained by someone? I don't think I am able to do it, but this is crucial to teach how to write or compile externals…
I’d also note that one reason why OF went with Github repos and an external scraper to provide the listings is that it maintains itself. People contribute and log issues with the addons directly and nobody has to manually update a list somewhere. All addon info is kept directly with the source aka documentation via the readme too.
I know puredata.info is a wiki and people have posted source code etc to it but often that info is out of date by the time I find it. This is why it can be a good idea to keep things close to the source (code).
Now I’m not saying this has to be *the way*. We standardized around using Github in OF as the project really expanded in scope and collaboration when the main OF source code was moved on it, so it was a natural fit.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 17, 2014, at 10:41 PM, Dan Wilcox danomatika@gmail.com wrote:
It can be maintained. If we have a “puredata” Github organization (I made one already :D), for example, there could be an external template with the makefiles, sample readme, folder structure, metadata, etc.
This is what we do with OpenFrameworks. There is an ofxAddonTemplate https://github.com/openframeworks/ofxAddonTemplate that is both documentation and a template when creating a new addon. We then provide makefiles and a ProjectGenerator app that work with this layout and, if the addon is in the right place, make it relatively easy to include the external sources and libs into your project. Now, pd externals wouldn’t require a project generator but would need a makefile that find the pd sources and builds against them and/or any other required libs. Again, we can borrow form the great OF makefiles in this regard.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 17, 2014, at 10:33 PM, Jaime E Oliver <jaime.oliver2@gmail.com mailto:jaime.oliver2@gmail.com> wrote:
Hans has already put together an external template and makefiles and I’m sure we could build similar indexing site for pd-externals (or I can ask for the ofxaddons.com http://ofxaddons.com/ source code).
Is this being maintained by someone? I don't think I am able to do it, but this is crucial to teach how to write or compile externals…
guess the subject of the thread is misleading
agreed, sorry
2014-12-18 1:11 GMT-02:00 Jaime E Oliver jaime.oliver2@gmail.com:
Hi all,
I guess the subject of the thread is misleading, perhaps we should be talking about an external repository rather than "extending" vanilla?
I'd certainly be interested in contributing my own externals.
best,
Jaime
On Dec 17, 2014, at 9:33 PM, Alexandre Torres Porres porres@gmail.com wrote:
Hello, I don't know if Hans is replaceable and I didn't mean to start a thread about "replacing" him or even point to a new "extended"distro.
I just wanted to highlight what miller mentioned about people considering working on a repository of external objects compatible to vanilla, and how all extended libs should work on vanilla and that he was willing to help make'm work in it.
I, for one, think that's good enough to work as an "extended" replacement, while hans (or any other who'd replace him) carries on with pd-extended (or some new distro).
As far as library management and maintenance goes. In my opinion, maybe that shouldn't be a burden that someone has to carry alone. I don't believe Hans vouched for being the one responsible for maintaining that much libraries on his own. I believe he ended up doing so because the original developers just didn't care anymore and abandoned it...
I have to say that's a hell of a bummer. And that I've had some experiences trying to reach creators and maintainers about a bug on some extended object and got not much help of something like "yeah, I know about it but I don't have time to work on it".
I love the work Hans did with Pd extended, and still use it, but I'm critic on how many libraries and objects are badly maintained, with bugs and not that good documentation. There are also many redundanct objects. So can't say it's such a great package of externals...
I know there are a few libraries I can't live without. Like, from the top of my head there are: zexy, iemlib, cyclone... I'd be kinda done with these few libraries.
In the scenario context we're discussing - of a repository of working libraries - if whoever made a library that was on the repository and, for some reason, it stopped working, I guess the creator should care to maintain it. but if he doesn't, if it's open source and everything, maybe someone else who cares would care to step in and deal with it.
But I have the idea that if a library is working fine as an external in vanilla, it should normally keep working as such. And Miller is here waving . And well, if it doesn't and nobody cares. Then it is crossed out of the repository. Simple as that...
So, it's a whole different paradigm. It's not about building and releasing a new distro. It's not about telling Miller what he should do with Vanilla. And it should be pretty simple as I see it. Moreover, I could manifest the opinion that that's the easy way and how it should be - a list of plugins, nicely organised somewhere, for people to download and use it.
And no need for that much diplomacy. I think it should be open and free. If people make some libraries and wanna to put it on the repository, just let'em do it.
Well, that's my two cents
Cheers
2014-12-17 18:08 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:
Who is going to replace Hans?
Here's an incomplete list of the responsibilities such a person would have:
- all the technical responsibilities of maintaining releasing software
(whether that software is a collection of libraries or a full distro of Pd, the work required is still comparable)
- maintaining the abandoned libs that users still need
- responding to requests from new developers in a timely manner
- being a leader. For example, when someone asks a question whether
doing X is feasible, you would give a clear and definitive answer based on where you think the project should go
- being a diplomat. After someone has done the work you encouraged them
to do and Miller says he wants to take another decade to think of a better solution, you have to find a compromise that doesn't discourage the development effort (and create yet another unmaintained lib or patch/plugin for Vanilla)
- generally encouraging development efforts of developers with various
styles of communication and expectations for the software
- working with developers like me who have essentially given up on trying
to get improvements into Pd Vanilla. (But I am happy to work with anyone willing to do all this work)
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello list,
Here my two cents.
From PD user POV, I can say that I LOVE pd-vanilla. Mainly beacuse I love almost every vanilla-"thing". Just a matter of philosophy. You have the base system that you can extend following your needs.
But, there are at least two things that makes pd-extended a desirable choice (at least for ME):
- Intallation on a new machine is almost a matter of few clicks. Im my
home PC, that's not a problem, but when you are in a tight scheduling, that can make the difference. 2. When I work on PD, after hours of patching, I find the pd-extended patch rendering UI less tiring than pd-vanilla's one. I'm not the "eye-candy" guy, but with the patch rendering of pd-vanilla, after a while, I've some difficulties in identify objects at first sight and stuff like that (I know, maybe it's just me :) ).
Based on this two "requisites" and recalling other posts in this thread, _my_ ideal scenario is the following.
- Pd-vanilla with the patch rendering of pd-extended (I have no idea of
the amount of work needed to obtain this, maybe someone has the answer). 2. A BINARY repository, or whatever, that provides a simple way to select and install the externels that I need without go to each externals developer website, and download, compile, ... .
The number (2) seems to be the most critical step. At this point, questions come:
- Every external works as-is with pd-vanilla?
- It's clear that the most "efficient" (?) externals repository must be
platform-based. For example, the most intuitive way to install things for an Ubuntu user is to fire up apt/synaptic ad click on this and that and click install. But from a developer point of view that means you have to create a repository for Ubuntu users, a repo for Fedora, a repo for OSX, for WIN, and so on and so forth. I think this strategy can be very developer-hungry :) (i.e. one or more mainter for each repo?). Another "ideal" scenario is to have a pd internal packaging system (i.e. a pd menu item called "extensions" that pops up a window in which you can chose the extension to install for your PLATFORM). Hummm... it seems a LOT of work for this! :) A trade-off can be a web page, with binary download link. The page can be generated automatically, and the duty of the mainters is to compile the extensions for different platforms and put those "on the website".
I will be happy to work with anyone who wants to collaborate :)
Ceers
Alessio
On 17/12/2014 17:08, Alexandre Torres Porres wrote:
Hello, I'm opening a new thread about the new direction of discussion with a proper subject title. Perhaps this will call the attention of other readers.
I particularly think this is of major interest to everyone. We're discussing new ways of using the libraries in Pd Extended into Pd Vanilla, and even a way to bring some of the Pd-extended UI changes into vanilla.
Something Miller brought up in the thread was "/Just FYI…. Joe Deken of newblankets.org http://newblankets.org/ is considering making a repository of external objects compatible with Pd vanilla. I think almost all the/ /objects in Pd extended will work with vanilla (and if I find out what specific changes vanilla would need to allow the others, I'd be happy to try to provide them). It seems like maintaining compiled versions of the //libs is an easier thing to do than maintaining all of Pd Extended/."
So, anyone else care to share their two cents?
cheers
[CUT]
-
Alessio Degani -
Alexandre Torres Porres -
Dan Wilcox -
Jaime E Oliver -
Jonathan Wilkes