[PD] [Bulk] Re: [Bulk] Extending Vanilla (was Cyclone help patches & issue list)

Ivica Bukvic ico at vt.edu
Sat Dec 20 11:28:42 CET 2014


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.

Best,

Ico
On Dec 19, 2014 1:49 PM, "Alexandre Torres Porres" <porres at gmail.com> wrote:

> 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 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
>> 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 at 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 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 -> http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>> --
>> a.
>>
>>
>> _______________________________________________
>> 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 ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141220/4a40eafb/attachment.html>


More information about the Pd-list mailing list