[PD] Updated pd-extended

[Hans-Christoph Steiner]

You've done a lot of good work in pd-l2ork, but you also broke binary
compatibility of libraries for no good reason.  You could have implemented
that feature in a way that preserved binary compatibility of libraries.  You
still can, and you should.

.hc

Ivica Bukvic wrote:
> 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.
> 
> Best,
> 
> Ico
> 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
>>
>>
>>
>>
>> N�n�r����)em�h�yhiם�w^��