[PD] Updated pd-extended

[Hans-Christoph Steiner]

You can take an external compiled for the same OS/arch and it loads and works
on all of them.

.hc

Ivica Bukvic wrote:
> Based on what metrics?
> On Sep 25, 2014 11:05 AM, "Hans-Christoph Steiner" <hans at at.or.at> wrote:
> 
>>
>> 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.
>>
>> .hc
>>
>> 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
>>>>
>>