Yep Alessio. It's time to mean business. So I volunteer

1. Identify which externals to include in the repo (for linux users, the folder /usr/lib/pd-extended/extra can be a good starting point)

The Pd extended libraries is a good starting point for all OS users, I guess. Not that I love all that there is there. IMHO there's a lot of junk. Even in the libraries I've mentioned I can't live without and are considered to be more stable I see some issues. Most of all, I'm usually unhappy about some help files that are quite crappy (like incomplete, sometimes the help files don't even work and you have to tweak them to hear something).

Other stuff I see, for example... just yesterday I learned about a new object for me, [LFO_noise~], and it's not working properly (it's frequency is twice than it should be). Other than that, it is redundanct, there are also two other objects that do exactly the same: [rand~] from cyclone and [noisi~] from zexy. I'd say just throw this "extra not working properly one away".

So I can volunteer to manage some of these libraries and rewrite the help files so that they are also vanilla compatible (that is, they don't call objects from other libraries, other than the ones from the same library).

I can't code! And I've compiled anything only a couple of times in my life. So I can't really help much with coding, and that's why I'd rather throw something away that doesn't properly work and has alternatives from other libraries. But I don't oppose if someone wants to fix stuff. I remember it wasn't exactly rock science to compile libraries, so I guess I can try and do it for the latest MAC OS systems on intel machines.

cheers

2014-12-19 9:51 GMT-02:00 Alessio Degani <alessio.degani@ymail.com>:

At this point I think that we can start to talk about technical stuff like roadmap, tasks, volunteers recruitment and so on :)

The basic steps, IMHO, can be:
1. Identify which externals to include in the repo (for linux users, the folder /usr/lib/pd-extended/extra can be a good starting point)
2. Identify which externals need to be compiled (some of them, as far as I rememer, are not "true" external library, but a pd patch [intrinsically cross-platform??])
3. Identify which externals are mainteined/unmaintained, and eventually, contact the maintainers just to say: "hello, we are creating a shared repo of externals. Are you interested? and so on..."
4. Prioritize (i.e. most used extensions have the priority).
5. Assign tasks

In that context, a web platform can help to accomplish this preliminary steps. For example github (that has a project wiki), or Azendoo (free -and simple!- collaborative project management), to name a few. I'm not an expert of this platform, but I use github for small projects and IMHO, Azendoo (or something like that) it can help a lot for discussions, task management and so on, without flooding the mailing list :)

Here is just my thoughts... any idea/suggestion/alternative are appreciated! :)

Cheers

Alessio

On 18/12/2014 20:50, Alexandre Torres Porres wrote:
Well, for starters, there could just be a repository with externals and libraries :)

I'm willing to help somehow. I'm not a programmer only, but I can help organising it and stuff. Testing libraries, listing it, etc.

Cheers

2014-12-18 17:34 GMT-02:00 IOhannes m zmölnig <zmoelnig@iem.at>:
On 12/18/2014 08:16 PM, Samuel Burt wrote:
> 1. Opening a patch with [import cyclone] would automatically download the

i *strongly* oppose to anything that automatically connects to the
internet and fetches or submits data.

mgfdsr
IOhannes

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- a.
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list