[PD] [Bulk] Re: [Bulk] Extending Vanilla (was Cyclone help patches & issue list)
Alexandre Torres Porres
porres at gmail.com
Sat Dec 20 14:05:16 CET 2014
cool, so I supose we could share this cleanup process... right?
I see a lot here about pd-l2ork, I've never used it cause I'm not on Linux
but it looks like it could be an alternative to extended if it could also
run in windows/mac OS. I'm assuming this has been asked/discussed before
over here, but I'll shoot again: any plans for that happening?
2014-12-20 8:28 GMT-02:00 Ivica Bukvic <ico at vt.edu>:
> FWIW, a good chunk of this cleanup is currently taking place in pd-l2ork.
> Namely, we are looking for redundant objects which are then disabled and
> replaced by legacy abstractions where possible or linked to other objects
> with identical or near identical functionality (again, where possible); we
> are disabling problematic objects that have design issues (e.g. foxy and
> flatspace IIRC), as well as looking to replace those with new objects that
> provide said functionality the right way. Finally, we are looking to
> standardize documentation (e.g. pd-l2ork has documentation for the entire
> cyclone adapted to the pddp format). If anyone desires git access to assist
> with this, please let us know.
> Please note that in this process the primary goal/mission/mantra is to
> create a clean and consistent environment for new users which may also mean
> that some of us weathered PD users may have to adapt our old patches
> because certain objects may not be available anymore.
> On Dec 19, 2014 1:49 PM, "Alexandre Torres Porres" <porres at gmail.com>
>> 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
>> 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
>> 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.
>> 2014-12-19 9:51 GMT-02:00 Alessio Degani <alessio.degani at 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
>>> 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! :)
>>> 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.
>>> 2014-12-18 17:34 GMT-02:00 IOhannes m zmölnig <zmoelnig at iem.at>:
>>>> On 12/18/2014 08:16 PM, Samuel Burt wrote:
>>>> > 1. Opening a patch with [import cyclone] would automatically download
>>>> i *strongly* oppose to anything that automatically connects to the
>>>> internet and fetches or submits data.
>>>> Pd-list at lists.iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
>>> _______________________________________________Pd-list at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>> Pd-list at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list