[PD] libpd separating gui from core

[Ivica Bukvic]

On Sun, Feb 23, 2014 at 4:40 PM, Dan Wilcox <danomatika at gmail.com> wrote:

> On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
>
>
> Yeah, stuff like that we should be able to solve. I'm not for ditching the
> Tcl/Tk gui at all. The work you and Ivica have been doing seems to be going
> a long way to fix this. Great! I just really hope this goes back into
> vanilla somehow or can be split up into between libpd and a gui
> implementation, etc. Otherwise, I fear a return to DD.
>

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.


>
> Things maybe acceptable to us PD "grey beards", but at some point it would
> be nice to find a way to enter the modern, multicore multithreaded world.
> Moores law has shifted from clock speed to "just add more cores" years ago
> now, so it's not like "buy a faster machine" is going to magically solve
> single threaded speed issues.
>
>
> It's not acceptable, but if you want to move forward _and_ do work that
> will be in sync with or accepted into Pd vanilla I don't see a way forward.
>  I can't even get help docs into Pd vanilla, and they were written to the
> PDDP spec that this community came up with and approved.  And as you know,
> there's a publicly viewable list of the same exact frustrations from all
> kinds of developers with various styles of communication.
>
>
> This is what I'm worried about and if that's truly the case, why bother
> really?
>

Because you said it earlier--you feel like you failed convincing your
colleagues pd is a viable option and that implies that you care and would
like to move the project forward. I would say it is not your fault because
you're not the only one who experienced that. The vanilla implementation
has an incredible backwards compatibility that unfortunately hampers its
progress. I truly admire Miller's pioneering work as well as his ongoing
efforts on maintaining pd. But let us not also forget that he also has an
incredible vision to allow forks like pd-extended, pd-l2ork, libpd, eapd,
now defunct dd, and many other (yes, I call them forks even though some try
to closely adhere to the core compatibility). I myself adhere to the idea
that I promote backwards compatibility as long as it does not prevent
progress. More so, I see backwards compatibility being way overstated,
particularly when it comes to source code as each release includes
version-specific compiled externals, making this a moot point. Sure, there
are behavioral corrections one needs to make to their patch ecosystem but I
guess that is the price of progress. Think about the leap Apple did with
OS9->OSX transition, and then later with G5->Intel, etc. The downside is a
lot of stuff broke. The upside? They are now one of the largest company in
the world that emerged from the ashes of a bankruptcy bailout. I do
understand I am here correlating pd to a corporation--arguably a dubious
endeavor, but only so if one fails to realize the core question:

What is more important to you: keeping backwards compatibility or moving
the project forward? A question that applies to both regardless of their
ostensibly orthogonal roots. Apparently, for Miller it is former (which is
something I greatly respect him for), and for me it is latter.



> At the very least, we should be able to run a performance intensive GEM
> patch with real time audio without drop outs *while* editing.
>
>
> Did you use any of the Pd-l2ork versions before it moved to Tkpath? It
> didn't solve the *_getrect problem I mentioned above, but it solved a whole
> lot of the problems that cause dropouts while editing, mainly by shooting
> way fewer messages across the socket.
>
>
> True, but will that be integrated back into vanilla? It's the same problem
> again ...
>

Knowing the pd dev cycle, it is unlikely. In my last conversation with
Miller, he did mention interest in porting my infinite undo and preserving
stacking order (undo depends on it), so that may happen at some point. As
for the rest--unlikely. And I am perfectly fine with that. Because,
ultimately it is all about the productivity--if infinite undo truly makes
that much of a difference, installing pd-l2ork is as easy as it gets, and
the price you pay to stay within that ecosystem is potentially losing some
of the backwards compatibility. Ask yourself if the shortcomings outweigh
benefits and you'll have your answer. Then again, you can always use
pd-vanilla/extended for your older projects as the source will be always
there in perpetuity under a license you cannot refuse.

So, what does all this amount to? I guess, rather than spending time
debating something that has been debated to death, if you feel so strongly
about this change, feel free to join forces with the rest of the pd-l2ork
devs (Jonathan is already contributing a ton)--at the very least we will do
our best to merge your contributions as we've done over the past years as
our dev base has grown. And who knows, maybe at some point in the future it
all will get merged back. And if not, it's still a win-win proposition if
this makes your life easier even if only temporarily...

HTH

Disclaimer: none of what I said was in any shape or form meant to be
inflammatory. Potential efforts at starting flame wars will be left
unheeded--I would much rather hack pd-l2ork code ;-)



>
> --------
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>
>
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140223/1aea4932/attachment.htm>