<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:12pt">Oops-- by "arguments of the parent" I mean arguments of the parent abstraction.<br><br>-Jonathan<br><div><span><br></span></div><div style="display: block;" class="yahoo_quoted"> <br> <br> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12pt;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> On Monday, February 24, 2014 2:44 PM, Jonathan Wilkes <jancsika@yahoo.com> wrote:<br> </font> </div> <div class="y_msg_container"><div id="yiv1004225655"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:12pt;"><div
id="yiv1004225655"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:12pt;">So let's just take a concrete example: "$@" syntax. It is a dollarsign variable in Pd-l2ork (and maybe in Pd-extended-- can't remember) and it expands to the incoming arguments. In an object box this expands to the arguments of the parent. The code for this feature affects Pd's message parser, which is in "the core". This is just an example-- there is a whole category of features which require changes to core code like this one.<br clear="none"><br clear="none">If you have a description of a democratic development process that can implement such a feature by wrapping Pd Vanilla in a GUI wrapper, document how it works, and
if it's maintainable I'll help you implement it.<br clear="none"><br clear="none">-Jonathan<span id="yiv1004225655yui_3_13_0_ym1_7_1393266073555_145"></span><div class="yiv1004225655yahoo_quoted" id="yiv1004225655yui_3_13_0_ym1_7_1393266073555_98" style="display:block;"> <br clear="none"> <br clear="none"> <div class="yiv1004225655yqt4587537029" id="yiv1004225655yqt04599"><div class="yiv1004225655yqt0210869347" id="yiv1004225655yqt26671"><div class="yiv1004225655yui_3_13_0_ym1_1_1393266073555_10924" style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:12pt;"> <div class="yiv1004225655yui_3_13_0_ym1_1_1393266073555_10925" style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:12pt;"> <div dir="ltr"> <font face="Arial" size="2"> On Monday, February 24, 2014 1:56 PM, Ivica Ico Bukvic <ico@vt.edu> wrote:<br clear="none"> </font> </div> <div
class="yiv1004225655y_msg_container"><div id="yiv1004225655"><style>#yiv1004225655 --
filtered {panose-1:2 4 5 3 5 4 6 3 2 4;}
#yiv1004225655 filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}
#yiv1004225655 filtered {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}
#yiv1004225655
p.yiv1004225655MsoNormal, #yiv1004225655 li.yiv1004225655MsoNormal, #yiv1004225655 div.yiv1004225655MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}
#yiv1004225655 a:link, #yiv1004225655 span.yiv1004225655MsoHyperlink
{color:blue;text-decoration:underline;}
#yiv1004225655 a:visited, #yiv1004225655 span.yiv1004225655MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
#yiv1004225655 span.yiv1004225655EmailStyle17
{color:#1F497D;}
#yiv1004225655 .yiv1004225655MsoChpDefault
{}
#yiv1004225655 filtered {margin:1.0in 1.0in 1.0in 1.0in;}
#yiv1004225655 div.yiv1004225655WordSection1
{}
#yiv1004225655 </style><div><div class="yiv1004225655WordSection1"><div class="yiv1004225655MsoNormal"><span style="font-size:11.0pt;"> </span></div><div class="yiv1004225655MsoNormal"><span style="font-size:11.0pt;"> </span></div><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt;"><div><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in;"><div class="yiv1004225655MsoNormal"><b><span style="font-size:10.0pt;">From:</span></b><span style="font-size:10.0pt;"> Dan Wilcox [mailto:danomatika@gmail.com] <br clear="none"><b>Sent:</b> Monday, February 24, 2014 11:34 AM<br clear="none"><b>To:</b> Ivica Bukvic<br clear="none"><b>Cc:</b> Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann<br clear="none"><b>Subject:</b> Re: [PD] libpd separating gui from core</span></div></div></div><div class="yiv1004225655MsoNormal"> </div><div><div class="yiv1004225655MsoNormal">On Mon, Feb 24, 2014 at
12:29 AM, Ivica Bukvic <<a rel="nofollow" shape="rect" ymailto="mailto:ico@vt.edu" target="_blank" href="mailto:ico@vt.edu">ico@vt.edu</a>> wrote:</div><div><div><blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in;"><div><div><div class="yiv1004225655MsoNormal"> </div><div><div><div class="yiv1004225655MsoNormal">On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox <<a rel="nofollow" shape="rect" ymailto="mailto:danomatika@gmail.com" target="_blank" href="mailto:danomatika@gmail.com">danomatika@gmail.com</a>> wrote:</div><div><div><div class="yiv1004225655MsoNormal"> </div></div></div><blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in;"><div><div><div><div class="yiv1004225655MsoNormal">I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla +
externals.</div></div></div></div></blockquote><div><div class="yiv1004225655MsoNormal"> </div></div></div><div><div class="yiv1004225655MsoNormal">I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward?</div></div></div></div></div></blockquote><div><div class="yiv1004225655MsoNormal"> </div></div><div><div class="yiv1004225655MsoNormal">I think you're missing my point here. With Pd-extended, you know you would make things which would work with Pd-vanilla if it had the appropriate externals compiled and available. With Pd-L2ork, there's a good chance that will not be the case as you move forward, thus fragmenting people between the apps. The Linux distro analogy is not a very apt one as there are far fewer PD users by comparison.</div><div class="yiv1004225655MsoNormal"><span style="font-size:11.0pt;"> </span></div><div
class="yiv1004225655MsoNormal"><span style="font-size:11.0pt;">But what if breaking things will bring more people in? (I ask this fully realizing I am playing a devil’s advocate here since I have no proof of this being the case with pd-l2ork nor that this will ever be even remotely close to the success of libpd)</span></div></div><div><div class="yiv1004225655MsoNormal"> </div></div><div><div class="yiv1004225655MsoNormal">I'm not saying it *will* happen or that it's your stated goal to split things, I'm just trying to suggest again that there could be a middle ground that could work for both Miller's and the communities goals. Other projects have managed that, why can't ours. Obviously, trying to push all updates and requirements back to the source have not worked, but maybe we can decided upon a subset of things that could/should be in the core and find a way to implement them. Again, I think gui abstraction could be a way to help
this.</div></div><div><div class="yiv1004225655MsoNormal"> </div></div><div><div class="yiv1004225655MsoNormal">I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also know you've been trying to integrate changes back into the Pd-vanilla. I just think that there must be another way.</div><div class="yiv1004225655MsoNormal"><span style="font-size:11.0pt;"> </span></div><div class="yiv1004225655MsoNormal"><span style="font-size:11.0pt;">I am all ears :-)</span></div></div><div><div class="yiv1004225655MsoNormal"> </div></div><blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in;"><div><div><div><div><blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in;"><div><div><div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;"><div><div><div class="yiv1004225655MsoNormal">That
said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility.</div></div></div></blockquote><div><div class="yiv1004225655MsoNormal"> </div></div></div><div><div class="yiv1004225655MsoNormal">Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying.</div></div><div><div
class="yiv1004225655MsoNormal"> </div></div><div><div class="yiv1004225655MsoNormal">Also, I'd like to point that, "bogged down" or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ...</div></div></div></div></blockquote><div><div class="yiv1004225655MsoNormal"> </div></div></div><div><div class="yiv1004225655MsoNormal">A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut
up.</div></div></div></div></div></blockquote><div><div class="yiv1004225655MsoNormal"> </div></div><div><div class="yiv1004225655MsoNormal">Less relevant? The libpd code is Pd-vanilla. It already works and is backwards compatible. This way at least you know that if it works in Pd-vanilla when patching it will work in libpd. Should we diverge to make custom changes we need and then require an entire new gui for people to build patches for libpd only? As it is now, libpd development is largely pd development and that's a good thing overall. If we can manage the architectural changes that were required for libpd (by Peter Brinkmann), then I don't see why we can't find a reasonable way to integrate some of the things that are needed for more advanced guis etc. The rest can be modular in tcl/tk and externals.<span style="color:#1F497D;"></span></div></div><div><div class="yiv1004225655MsoNormal"> </div></div><div><div
class="yiv1004225655MsoNormal">I'd love to use Pd-L2ork, but how long will it be compatible with libpd? I don't want to build a bunch of patches around new functionality that just won't work on a mobile phone and would be harder to debug.</div></div><div><div class="yiv1004225655MsoNormal"> </div></div><blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in;"><div><div><div><div><blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in;"><div><div><div><div class="yiv1004225655MsoNormal">If the reality is as you say, then I'm not really interested in spending my time hacking on our little island.</div></div></div></div></blockquote><div><div class="yiv1004225655MsoNormal"> </div></div></div><div><div class="yiv1004225655MsoNormal">And the only thing I can say at this point is that I respect that and to thank
you for your genuine effort at moving the community forward.</div></div></div></div></div></blockquote></div><div class="yiv1004225655MsoNormal"><br clear="none">That remake was hasty of mine and short sighted. My background is in engineering and I hate seeing effort split up and duplicated on things that we all want/need. If we all respect Miller, maybe we can also respect that we could find a middle ground with both his goals and ours.<span style="color:#1F497D;"></span></div><div class="yiv1004225655MsoNormal"><span style="font-size:11.0pt;"> </span></div><div class="yiv1004225655MsoNormal"><span style="font-size:11.0pt;">I’ve said it many times and I’ll happily say it again—I have nothing but utmost respect for Miller and Miller’s work. Yet, based on my conversations with Miller, I have my doubts that there will ever be a middle ground—the goals are too divergent for one code base to meet both needs in a way that also satisfies your
and my (and apparently others’) sense of urgency. That said, I’ve been proven wrong many times before, so please don’t let this stop you.</span></div><div class="yiv1004225655yqt9141602613" id="yiv1004225655yqtfd51959"></div><div class="yiv1004225655yqt9141602613" id="yiv1004225655yqtfd69321"><div class="yiv1004225655MsoNormal"><br clear="all"></div><div><div class="yiv1004225655MsoNormal"> </div></div><div class="yiv1004225655MsoNormal">-- <br clear="none">Dan Wilcox<br clear="none"><a rel="nofollow" shape="rect" target="_blank" href="http://danomatika.com/">danomatika.com</a><br clear="none"><a rel="nofollow" shape="rect" target="_blank" href="http://robotcowboy.com/">robotcowboy.com</a> </div></div></div></div></div></div></div></div><br clear="none"><br clear="none"></div> </div> </div></div></div> </div> </div></div></div></div></div></div><br><div class="yqt4587537029" id="yqt22887">_______________________________________________<br
clear="none"><a shape="rect" ymailto="mailto:Pd-list@iem.at" href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a shape="rect" href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br><br></div> </div> </div> </div> </div></body></html>