<p dir="ltr"><br>
On Dec 20, 2014 2:05 PM, "Alexandre Torres Porres" <<a href="mailto:porres@gmail.com">porres@gmail.com</a>> wrote:<br>
><br>
> cool, so I supose we could share this cleanup process... right?<br>
><br>
> 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?</p>
<p dir="ltr">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.</p>
<p dir="ltr">Best,</p>
<p dir="ltr">Ico</p>
<p dir="ltr">><br>
> cheers<br>
><br>
> 2014-12-20 8:28 GMT-02:00 Ivica Bukvic <<a href="mailto:ico@vt.edu">ico@vt.edu</a>>:<br>
><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> Best,<br>
>><br>
>> Ico<br>
>><br>
>> On Dec 19, 2014 1:49 PM, "Alexandre Torres Porres" <<a href="mailto:porres@gmail.com">porres@gmail.com</a>> wrote:<br>
>>><br>
>>> Yep Alessio. It's time to mean business. So I volunteer<br>
>>><br>
>>> 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)<br>
>>><br>
>>> 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). <br>
>>><br>
>>> 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". <br>
>>><br>
>>> 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).<br>
>>><br>
>>> 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.<br>
>>><br>
>>> cheers<br>
>>><br>
>>> 2014-12-19 9:51 GMT-02:00 Alessio Degani <<a href="mailto:alessio.degani@ymail.com">alessio.degani@ymail.com</a>>:<br>
>>>><br>
>>>> At this point I think that we can start to talk about technical stuff like roadmap, tasks, volunteers recruitment and so on :)<br>
>>>><br>
>>>> The basic steps, IMHO, can be:<br>
>>>> 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)<br>
>>>> 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??])<br>
>>>> 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..."<br>
>>>> 4. Prioritize (i.e. most used extensions have the priority).<br>
>>>> 5. Assign tasks<br>
>>>><br>
>>>> 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 :)<br>
>>>><br>
>>>> Here is just my thoughts... any idea/suggestion/alternative are appreciated! :)<br>
>>>><br>
>>>> Cheers<br>
>>>><br>
>>>> Alessio<br>
>>>><br>
>>>><br>
>>>> On 18/12/2014 20:50, Alexandre Torres Porres wrote:<br>
>>>>><br>
>>>>> Well, for starters, there could just be a repository with externals and libraries :)<br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>> Cheers<br>
>>>>><br>
>>>>> 2014-12-18 17:34 GMT-02:00 IOhannes m zmölnig <<a href="mailto:zmoelnig@iem.at">zmoelnig@iem.at</a>>:<br>
>>>>>><br>
>>>>>> On 12/18/2014 08:16 PM, Samuel Burt wrote:<br>
>>>>>> > 1. Opening a patch with [import cyclone] would automatically download the<br>
>>>>>><br>
>>>>>> i *strongly* oppose to anything that automatically connects to the<br>
>>>>>> internet and fetches or submits data.<br>
>>>>>><br>
>>>>>> mgfdsr<br>
>>>>>> IOhannes<br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
>>>>>> UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
>>>>> UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>> -- <br>
>>>> a.<br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
>>>> UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br>
>>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
>>> UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br>
>>><br>
><br>
</p>