[PD] Updated pd-extended

Hans-Christoph Steiner hans at at.or.at
Thu Sep 25 17:05:40 CEST 2014

For libraries, there is binary compatibility between pd vanilla, extended,
desiredata, and vibrez.  desiredata made much larger changes to the GUI-side
than pd-l2ork.


Ivica Bukvic wrote:
> Why is this such a problem? I did not break source compatibility (well,
> some of it will happen for gui objects as a result of porting gui to qt)
> and for every extended release you recompile new binaries anyhow and so
> does pd-l2ork, except that pd-l2ork goes even one step further offering a
> monolithic release. Besides, pd is not java and there is no binary
> compatibility across different platforms (except maybe libpd realized in
> java, but that is not what we are talking about here). Under such
> circumstances, I see binary compatibility strictly as a means of
> maintaining status quo. As a final thought, consider that a lot of good
> work (as you called it, and I thank you for your kind words) would not have
> been possible without breaking binary compatibility which, given the
> aforesaid circumstances, is a non-issue to begin with.
> Best,
> Ico
> On Sep 25, 2014 10:54 AM, "Hans-Christoph Steiner" <hans at at.or.at> wrote:
>> 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^��
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list

More information about the Pd-list mailing list