[PD] libpd separating gui from core

[Ivica Bukvic]

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

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 ;-)

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

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.


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
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140223/f9d2c5df/attachment-0001.htm>