[PD] libpd separating gui from core

[Dan Wilcox]

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





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