[PD] libpd separating gui from core

[Dan Wilcox]

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 <jancsika at 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 <ico at vt.edu>
> wrote:
>
>
> *From:* Dan Wilcox [mailto:danomatika at gmail.com]
> *Sent:* Monday, February 24, 2014 11:34 AM
> *To:* Ivica Bukvic
> *Cc:* Jonathan Wilkes; pd-list at iem.at List; Peter Brinkmann
> *Subject:* Re: [PD] libpd separating gui from core
>
> On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic <ico at vt.edu> wrote:
>
>
> On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox <danomatika at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140224/bc794527/attachment-0001.htm>