[PD] libpd separating gui from core

[Dan Wilcox]

On Feb 23, 2014, at 10:46 PM, Ivica Bukvic <ico at vt.edu> wrote:

> libpd requires a lot of what pd-l2ork offers in order to be able to move forward (obeying stacking order for instance, that are a prerequisite for global system-wide presets as well as editing tools like undo/redo and tofront/back).

Those sound like things that should/could be in the core.

> pd-l2ork also improves on pack, route, select, and trigger to make things easier for newcomers to understand and for professionals to get to their results faster. None of these are a part of the core and yet they very much belong to libpd...

Those are objects and they can simply alias the existing objects on load, that or add an option to the core to not load existing objects / allow conditional calls the the object setup functions.

> I simply don't see fragmentation as a bad thing. Look at Linux--fragmentation galore. And yet we all get along just fine (well for the most part ;-)

The kernel is fragmented? Your talking distros and I see things going more Linux & BSD.

> If it will make it any easier for you, refer to pd-l2ork as anchovies and forget for a moment that it has any compatibility with pd whatsoever. This could ostensibly become a reality in not so distant future from now (well the compatibility part, not so sure about the name).

I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals.

> 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 ...

If the reality is as you say, then I'm not really interested in spending my time hacking on our little island.

> On Sun, Feb 23, 2014 at 9:40 PM, Dan Wilcox <danomatika at gmail.com> wrote:
> Coming back on topic:
> 
> On Feb 23, 2014, at 8:15 PM, Ivica Bukvic <ico at vt.edu> wrote:
> 
>> If I may chime in for a sec (pd-l2ork author here), there is absolutely no interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already has thousands of lines of code either altered or added and I have no intention of slowing down. Likewise, in part because I tried in the past, I have no interest in trying to get things merged into the core pd. I will very much welcome someone else's efforts to do so but knowing Miller's gargantuan goal of keeping backwards compatibility, I simply feel this approach is too time consuming for me to promote the rate of development I (and as it appears many others on this list) desire.
> 
> 
> Except I see there being a third middle, ground via libpd. IMO Miller is best at the core and the community is the best at adding functionality around it and creating a modern GUI.
> 
> My take on the future (and I believe Hans has brought this up as well):
> 
> If we could find a way to abstract the gui interface as libpd already does for midi and messaging, I see Pd-vanilla keeping the existing gui and using a single threaded libpd as the core. Then the forks utilize libpd for the core and wrap it with their newer, updated whizz-bang accelerated guis using perhaps a multithreaded libpd as their core.
> 
> We know the issues, if we can work out a way to solve what's needed for the gui abstraction and hopefully multi-threaded/multi-instance support added to the core then there's a way to have the best of both worlds. For instance, multi-threading support can and should be a compile time flag and it can simply be turned off in Pd-vanilla. It may involve some work and some pain, but I really think it must be possible.
> 
> My fear is that, in the long run, the forks may diverge too much from the more slowly evolving vanilla and eventually lose integration with it completely. That splits the community for real, one that is perhaps already too splintered. Pd-L20rk is really exciting, but it would be sad if it eventually might split off from the prime mover you (and we all) are so indebted too.
> 
> I guess what I'm saying in a nutshell is: I see libpd as the middle ground so Miller can focus on the pd core without the community and its forks having to muck up Pd-vanilla. It should be possible, I think we really just need to get all of the Pd devs in one room and hash out what that middle ground could be. Then we have a combined roadmap instead of hacking away in isolation.
> 
> Does that make sense at all? It seems so obvious to me and is one of the reasons why I'm working on libpd. For me, it's a sustainable future.
> 
> --------
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
> 
> 
> 
> 
> 
> 

--------
Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140223/2ccf2af7/attachment.htm>