<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 12, 2014 at 3:25 AM, Ivica Ico Bukvic <span dir="ltr"><<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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></div></blockquote><div><br></div><div>Fair enough. Thanks for the update!<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    
    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>
    </div></blockquote></div><br></div><div class="gmail_extra">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></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">Albert<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature"><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email:  <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a><br>WWW:    <a href="https://plus.google.com/+AlbertGraef" target="_blank">https://plus.google.com/+AlbertGraef</a></div></div>
</div></div>