[PD] Updated pd-extended

Ivica Bukvic ico at vt.edu
Tue Sep 23 16:57:22 CEST 2014

Well, I guess you can call me a "developer," whatever that means--I don't
care that much about titles. Yet, I would argue that as far as low level
stuff is concerned in recent years pd-l2ork has certainly pushed the
envelope in terms of core development. Even the feature that has earned me
the title in quotations delves so deep into the core that currently it
cannot be implemented in either vanilla or extended without significant
changes even though it retains full backwards compatibility. I would also
argue it is essential and offers a slew of features that are unavailable in
any other implementation of presets.

Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially
a conscious decision to allow for faster development while addressing the
lack of manpower. But that is about to change once we complete port to Qt
library. We already transitioned to Tkpath quite a while ago which allowed
us to use a full SVG-based canvas, so I have no doubt we will be able to do
this again. Once this is done, we won't have to circumnavigate exceptions
Tk library requires in order to be compliant with different platforms and I
would argue in turn that will result in faster development. So, if you are
really interested in pushing the development of non-vanilla pd I think you
should heed some of Jonathan's advice and look for ways how community can
work together in combining the "best of" and engaging developers and
"developers" alike who have shown dedication to the cause. But before that
can be accomplished, the community should consider agreeing on design
choices. For instance, pd-l2ork came into existence because it focuses on
more nimble development at the expense of potential loss of backwards
compatibility (even though after 4 years of development the only
incompatibility we infatuated is correcting buggy positioning of iemgui
objects, which is cosmetic in nature) because a good chunk of that
compatibility stems from buggy implementations that stuck around long
enough that they became a part of the standard (e.g. iemgui's buggy
positioning of objects that are arbitrarily offset from their x and y
positions, as reported by the pd script), which is unfortunate.


On Sep 23, 2014 9:21 AM, "Dan Wilcox" <danomatika at gmail.com> wrote:

> I disagree. Your example lists what? 2 more developers? I'm talking about
> "developers" as in people working the C code, build scripts, tcl/tk etc aka
> people who could, theoretically, help push out a new Pd-extended release.
> True, we have plenty of people working on externals, but this is a problem
> for someone who can go deeper.
> I still maintain that the number of low level developers to overall users
> (non-developers) is relatively low.
> On Sep 23, 2014, at 6:00 AM, pd-list-request at lists.iem.at wrote:
> However, your description of the user/developer ratio doesn't ring true to
> me.  There's actually a surplus of developers and development energy-- I
> count two implementations of presets in the last year or two (in Pd-l2ork
> and the Chocolate et Coffee lib) which are in addition to however many
> already exist on svn and the Pd forum.
> --------
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
> _______________________________________________
> Pd-list at lists.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/20140923/7bfae420/attachment.html>

More information about the Pd-list mailing list