<p dir="ltr"><br>
On Nov 12, 2014 3:20 AM, "Albert Graef" <<a href="mailto:aggraef@gmail.com">aggraef@gmail.com</a>> wrote:<br>
><br>
> On Wed, Nov 12, 2014 at 3:25 AM, Ivica Ico Bukvic <<a href="mailto:ico@vt.edu">ico@vt.edu</a>> wrote:<br>
>><br>
>> I tend to disagree with this mainly because prepend does not output a genuine list, as it should but rather an "anything" which further confuses new users. That said, I offer a compromise--I've just committed earlier today an abstraction prepend.pd and its prepend-help.pd file as part of the cyclone library that essentially mimics the behavior of prepend.pd but also posts intentionally annoying warning in the console that this object is deprecated as well as what the users should use instead (namely [list prepend]). The help file also reflects this fact with a big red warning box at the top of it.<br>
><br>
><br>
> Fair enough. Thanks for the update!<br>
>  <br>
>><br>
>> Please note as we move forward we will have to prune a good number of 3rd party objects and provide some sort of an interim abstraction that substitutes its behavior. I am also looking to consolidate all externals into a single folder and drop the whole library_path/external_name nonsense which makes pd 3rd party ecosystem incredibly hard to navigate--I am open to alternative suggestions but I do want to also point out that I feel rather strongly about this. Your help/input in this process will be most appreciated.<br>
><br>
><br>
> That will surely offer some opportunity for interesting discussions. ;-) But I think that we'll be fine with it as long as there are suitable replacements for widely used objects and a clear migration path.<br>
><br>
> Compatibility works both ways, though. One issue to keep in mind is the rather limited range of systems where pd-l2ork is available right now. If you need to run your patches elsewhere (I'm thinking about OS X, specifically) then you have to fall back to either Pd-Extended or vanilla Pd + externals from the Pd repo. So maintaining some level of compatibility to the other flavors is desirable in order to avoid being locked into a single platform.</p>
<p dir="ltr">Very good point. This should get resolved once we compete port to qt at which point things should get progressively simpler in terms of supporting multiple platforms.</p>
<p dir="ltr">HTH</p>
<p dir="ltr">><br>
> Albert<br>
><br>
> -- <br>
> Dr. Albert Gr"af<br>
> Computer Music Research Group, JGU Mainz, Germany<br>
> Email:  <a href="mailto:aggraef@gmail.com">aggraef@gmail.com</a><br>
> WWW:    <a href="https://plus.google.com/+AlbertGraef">https://plus.google.com/+AlbertGraef</a><br>
><br>
> _______________________________________________<br>
> L2Ork-dev mailing list<br>
> <a href="mailto:L2Ork-dev@disis.music.vt.edu">L2Ork-dev@disis.music.vt.edu</a><br>
> <a href="http://disis.music.vt.edu/listinfo/l2ork-dev">http://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
</p>