[L2Ork-dev] a couple of questions

[Ivica Ico Bukvic]

On 11/11/2014 9:23 AM, Albert Graef wrote:
> On Mon, Sep 15, 2014 at 10:34 PM, Gilberto Agostinho 
> <gilbertohasnofb at googlemail.com 
> <mailto:gilbertohasnofb at googlemail.com>> wrote:
>
>     - As for [prepend] vs [list prepend], I think it could be nice to
>     leave obsolete objects in order to maximize compatibility (I have
>     seen many patches using [prepend]). On top of that, I believe that
>     [prepend] works not only with lists, but also with any strings,
>     and it is very useful to set a value to a message box (I requires
>     one less object to do this job). Have a look:
>     http://s12.postimg.org/f45zkztx9/foobar.png - or am I missing
>     something here?
>
>
> Sorry for unearthing this old thread, but it seems that the issue with 
> the missing cyclone objects hasn't been fixed yet. I just had someone 
> report it to me on the AUR (where I'm maintaining the Arch pd-l2ork 
> package).
>
> I consider this a real bug. Like it or not, but people have patches 
> made with other Pd flavors, which they would like to run with 
> pd-l2ork, and prepend apparently is one of those objects that actually 
> gets used by some people. Is there a really good reason to exclude 
> this specific object when everything else from cyclone is there? 
> Otherwise it just makes running "legacy" patches harder for no good 
> reason.

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.

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.

Best,

Ico

>
> Albert
>
> -- 
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email: aggraef at gmail.com <mailto:aggraef at gmail.com>
> WWW: https://plus.google.com/+AlbertGraef
>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> http://disis.music.vt.edu/listinfo/l2ork-dev

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico at vt.edu
www.performingarts.vt.edu
disis.music.vt.edu
l2ork.music.vt.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20141111/981c2676/attachment.html>