[PD] Updated pd-extended

Hans-Christoph Steiner hans at at.or.at
Wed Oct 1 16:51:37 CEST 2014


There were at least two proposals back when the change was made. They're in
the archives.  I certainly don't remember the details at this point.

.hc

Jonathan Wilkes wrote:
> Um... have you actually read the source for DesireData?
> 
> If someone wants to write me up a nice, concise, friendly non-sarcastic spec about how to change Pd-l2ork's code so that it can be binary compatible with the same features it currently has, I'll be happy to try implementing it.
> 
> -Jonathan
> 
> 
> On Thursday, September 25, 2014 12:04 PM, Ivica Bukvic <ico at vt.edu> wrote:
>  
> 
> 
> ...As strange as it may sound I must admit I've missed our broken conversations/banter. Welcome back, Hans!
> Alas, this time I will have to bow out--so many things to do, so little time. Hope you'll understand.
> Best,
> Ico
> On Sep 25, 2014 11:08 AM, "Hans-Christoph Steiner" <hans at at.or.at> wrote:
> 
> 
>> 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
>>>>>>
>>>>
>>
> _______________________________________________
> 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