[PD] libpd separating gui from core

[Dan Wilcox]

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.

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.

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.

-- 
Dan Wilcox
danomatika.com
robotcowboy.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140224/e83a0eda/attachment.htm>