[PD] enhance pd-extended with pd-l2ork featues ?

Ivica Ico Bukvic ico at vt.edu
Sun Jan 20 05:21:33 CET 2013


> > Why not simply use pd-l2ork?
> 
> I do, but possible reasons why someone might not use Pd-l2ork:
> * no binary for windows
> * no binary for OSX

On the flip-side pd-l2ork provides a solid, bug-free environment on Linux
and looks a lot more contemporary than the aged default tk iteration. In
other words, it is a targeted Linux distribution of pd (something that can
be easily lost in a cross-platform effort with inadequate developer support,
as I am sure Hans can attest to). At this point I would go as far as
challenge you to find something that does not work or exhibits a buggy
behavior (I can give you dozens of examples of not only superficial
functionalities, but core pd engine behaviors  that still do not work on
either pd or pd-extended and that work on pd-l2ork). Sure, there are a lot
of issues in making menus/browser more streamlined and making things
prettier, but that is a lot easier when you know that the core is solid.

What has IMHO happened between 0.42 and 0.43 (and onwards) is some fantastic
work by Miller, Hans, and the community. But it has also had a ton of
regressions since the rewrite was happening on top of a code base that still
had a generous amount of bugs (pd-l2ork bug-fix count in reference to the
original 0.42.6 branch is easily in hundreds), like JACK breakage that was
only recently fixed.

OTOH, windows and OSX builds should not be too hard to do. All it would take
is someone going through the pd.tk file and making sure that all
Linux-centric changes are proofed for other platforms, and there are not
that many of those. My bigger problem is dealing with all the support issues
that would detract from the solidification of the core (which is exactly
what we've done over the past 2 years) as my time is limited, and as I am
sure Hans can attest.

> * doesn't have gui plugin API

But it does have all core features that "just work." See, I am of the
conviction that the core needs to be solid before one delves into providing
bunch of fancy things on top of the foundation (even though one could easily
argue pd-l2ork has plenty of fancy things--let's not forget that magic glass
that made it eventually into pd-extended was first rewritten for pd-l2ork,
including fixes for several show-stopping bugs that were in old Joe Sarlo's
patch submission from the early 2000s; but these are all essentially
enhancements to the core functionality, many of which obsolete a number of
proposed plug-ins, like the one that hides the menu--pd-l2ork allows
per-patcher toggling of menu/ontop/scrollbars/etc. flags, making building
modular guis a heck of a lot easier). Otherwise, it is like slapping whipped
cream on top of dirt--it may look pretty, even appetizing at first sight,
but in the end it is still a piece of dirt with whipped cream on top
(disclaimer: I do not mean to imply that pd is "dirt" but am merely trying
to clarify my belief/approach through the use of a stark analogy). Another
thought is, if the core is done well enough, then no plugin should be
necessary (e.g. browser you developed will be something that will become the
core within pd-l2ork, not a plugin, once I've had a chance to check it for
all conceivable regressions/problems). Lastly, at some point in the future,
pd-l2ork may support plug-ins, or better yet, may assimilate plug-ins into
its core--my preference being latter as I am leaning more towards the "just
works" mentality. FWIW, I am of the conviction that once the core is truly
solid, further software development is a lot more nimble.

> * doesn't have all the translation stuff being done for pd-extended 0.43
(or
> does it?)

Pd-l2ork has initial UTF support but no translation, mainly because I am not
so keen on merging things that are still developing/evolving. When it is
ripe, it will be merged.

> * deb package is new and it may or may not cause problems with other
> installed pd debs

So far, there are no problems whatsoever. The only thing I added as of
earlier today is even more packages that it may conflict with from the
pd-extended 3rd party libs. OTOH it is a heck of a lot easier to install one
deb than dozens (and yes, I am aware that for maintainers it is easier to
have multiple libs as that is easier to maintain, but as OSX/iOS has taught
us, what is easier for a developer may not be easier for a user).

> * whatever was added in 0.43-- missing all that

Pd-l2ork is indeed missing *some* (IMHO yet to be complete) features, but
there are many that have been already merged. The only ones that haven't are
the ones I did not find to be complete enough to be merged or the ones that
are not critical but primarily cosmetic in nature (e.g. console verbosity)
that will be merged eventually. So, pd-l2ork is more like my attempt at "the
best of " 0.42 and 0.43 branches, if you like.

Best wishes,

Ico

> 
> -Jonathan




More information about the Pd-list mailing list