Exactly. If we can build a list of things that should/could be in the core, then we have a starting place to see if there is a way to work into into either vanilla or a wrapper like libpd.
As we do in OpenFrameworks, I've started a PiratePad for general ideas/requirements. Feel free to add to this: http://piratepad.net/PureData-middle-ground-ideas On Mon, Feb 24, 2014 at 2:44 PM, Jonathan Wilkes <jancs...@yahoo.com> wrote: > 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 <i...@vt.edu> > wrote: > > > *From:* Dan Wilcox [mailto:danomat...@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 core > > On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic <i...@vt.edu> wrote: > > > On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox <danomat...@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. > > > -- > Dan Wilcox > danomatika.com > robotcowboy.com > > > -- Dan Wilcox danomatika.com robotcowboy.com
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list