[PD] Updated pd-extended

Thu Sep 25 18:54:03 CEST 2014

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140925/1ff51d68/attachment-0001.html>