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.
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.
-Jonathan
On Monday, February 24, 2014 1:56 PM, Ivica Ico Bukvic <ico@vt.edu> wrote:
From: Dan Wilcox [mailto:danomatika@gmail.com]
Sent: Monday, February 24, 2014 11:34 AM
To: Ivica Bukvic
Cc: Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann
Subject: Re: [PD] libpd separating gui from coreOn Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic <ico@vt.edu> wrote:On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox <danomatika@gmail.com> wrote:I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals.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?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.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)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.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.I am all ears :-)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.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.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 ...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.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.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.If the reality is as you say, then I'm not really interested in spending my time hacking on our little island.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.
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.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.