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

Sat Dec 20 23:17:30 CET 2014

On Dec 20, 2014 2:05 PM, "Alexandre Torres Porres" <porres at gmail.com> wrote:
>
> 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?

Short answer is yes. It is probably usable as-is ( there may be a few
things to check TCL-side plus updating the autobuild script). I just never
bothered building it. Help on this front is most welcome. As far as my
priority list is concerned, I would like to finish qt port before delving
into OSX and Windows support because once that is complete, supporting
consistent GUI on all three platforms will become near seamless.

Best,

Ico

>
> cheers
>
> 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.
>>
>> 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/562f43a1/attachment-0001.html>