<p dir="ltr">...As strange as it may sound I must admit I've missed our broken conversations/banter. Welcome back, Hans!</p>
<p dir="ltr">Alas, this time I will have to bow out--so many things to do, so little time. Hope you'll understand.</p>
<p dir="ltr">Best,</p>
<p dir="ltr">Ico</p>
<div class="gmail_quote">On Sep 25, 2014 11:08 AM, "Hans-Christoph Steiner" <<a href="mailto:hans@at.or.at">hans@at.or.at</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
You can take an external compiled for the same OS/arch and it loads and works<br>
on all of them.<br>
<br>
.hc<br>
<br>
Ivica Bukvic wrote:<br>
> Based on what metrics?<br>
> On Sep 25, 2014 11:05 AM, "Hans-Christoph Steiner" <<a href="mailto:hans@at.or.at">hans@at.or.at</a>> wrote:<br>
><br>
>><br>
>> For libraries, there is binary compatibility between pd vanilla, extended,<br>
>> desiredata, and vibrez.  desiredata made much larger changes to the<br>
>> GUI-side<br>
>> than pd-l2ork.<br>
>><br>
>> .hc<br>
>><br>
>> Ivica Bukvic wrote:<br>
>>> Why is this such a problem? I did not break source compatibility (well,<br>
>>> some of it will happen for gui objects as a result of porting gui to qt)<br>
>>> and for every extended release you recompile new binaries anyhow and so<br>
>>> does pd-l2ork, except that pd-l2ork goes even one step further offering a<br>
>>> monolithic release. Besides, pd is not java and there is no binary<br>
>>> compatibility across different platforms (except maybe libpd realized in<br>
>>> java, but that is not what we are talking about here). Under such<br>
>>> circumstances, I see binary compatibility strictly as a means of<br>
>>> maintaining status quo. As a final thought, consider that a lot of good<br>
>>> work (as you called it, and I thank you for your kind words) would not<br>
>> have<br>
>>> been possible without breaking binary compatibility which, given the<br>
>>> aforesaid circumstances, is a non-issue to begin with.<br>
>>><br>
>>> Best,<br>
>>><br>
>>> Ico<br>
>>> On Sep 25, 2014 10:54 AM, "Hans-Christoph Steiner" <<a href="mailto:hans@at.or.at">hans@at.or.at</a>><br>
>> wrote:<br>
>>><br>
>>>><br>
>>>> You've done a lot of good work in pd-l2ork, but you also broke binary<br>
>>>> compatibility of libraries for no good reason.  You could have<br>
>> implemented<br>
>>>> that feature in a way that preserved binary compatibility of libraries.<br>
>>>> You<br>
>>>> still can, and you should.<br>
>>>><br>
>>>> .hc<br>
>>>><br>
>>>> Ivica Bukvic wrote:<br>
>>>>> Well, I guess you can call me a "developer," whatever that means--I<br>
>> don't<br>
>>>>> care that much about titles. Yet, I would argue that as far as low<br>
>> level<br>
>>>>> stuff is concerned in recent years pd-l2ork has certainly pushed the<br>
>>>>> envelope in terms of core development. Even the feature that has earned<br>
>>>> me<br>
>>>>> the title in quotations delves so deep into the core that currently it<br>
>>>>> cannot be implemented in either vanilla or extended without significant<br>
>>>>> changes even though it retains full backwards compatibility. I would<br>
>> also<br>
>>>>> argue it is essential and offers a slew of features that are<br>
>> unavailable<br>
>>>> in<br>
>>>>> any other implementation of presets.<br>
>>>>><br>
>>>>> Pd-l2ork's greatest deterrent is exclusivity to Linux, which was<br>
>>>> initially<br>
>>>>> a conscious decision to allow for faster development while addressing<br>
>> the<br>
>>>>> lack of manpower. But that is about to change once we complete port to<br>
>> Qt<br>
>>>>> library. We already transitioned to Tkpath quite a while ago which<br>
>>>> allowed<br>
>>>>> us to use a full SVG-based canvas, so I have no doubt we will be able<br>
>> to<br>
>>>> do<br>
>>>>> this again. Once this is done, we won't have to circumnavigate<br>
>> exceptions<br>
>>>>> Tk library requires in order to be compliant with different platforms<br>
>>>> and I<br>
>>>>> would argue in turn that will result in faster development. So, if you<br>
>>>> are<br>
>>>>> really interested in pushing the development of non-vanilla pd I think<br>
>>>> you<br>
>>>>> should heed some of Jonathan's advice and look for ways how community<br>
>> can<br>
>>>>> work together in combining the "best of" and engaging developers and<br>
>>>>> "developers" alike who have shown dedication to the cause. But before<br>
>>>> that<br>
>>>>> can be accomplished, the community should consider agreeing on design<br>
>>>>> choices. For instance, pd-l2ork came into existence because it focuses<br>
>> on<br>
>>>>> more nimble development at the expense of potential loss of backwards<br>
>>>>> compatibility (even though after 4 years of development the only<br>
>>>>> incompatibility we infatuated is correcting buggy positioning of iemgui<br>
>>>>> objects, which is cosmetic in nature) because a good chunk of that<br>
>>>>> compatibility stems from buggy implementations that stuck around long<br>
>>>>> enough that they became a part of the standard (e.g. iemgui's buggy<br>
>>>>> positioning of objects that are arbitrarily offset from their x and y<br>
>>>>> positions, as reported by the pd script), which is unfortunate.<br>
>>>>><br>
>>>>> Best,<br>
>>>>><br>
>>>>> Ico<br>
>>>>> On Sep 23, 2014 9:21 AM, "Dan Wilcox" <<a href="mailto:danomatika@gmail.com">danomatika@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>>> I disagree. Your example lists what? 2 more developers? I'm talking<br>
>>>> about<br>
>>>>>> "developers" as in people working the C code, build scripts, tcl/tk<br>
>> etc<br>
>>>> aka<br>
>>>>>> people who could, theoretically, help push out a new Pd-extended<br>
>>>> release.<br>
>>>>>> True, we have plenty of people working on externals, but this is a<br>
>>>> problem<br>
>>>>>> for someone who can go deeper.<br>
>>>>>><br>
>>>>>> I still maintain that the number of low level developers to overall<br>
>>>> users<br>
>>>>>> (non-developers) is relatively low.<br>
>>>>>><br>
>>>>>> On Sep 23, 2014, at 6:00 AM, <a href="mailto:pd-list-request@lists.iem.at">pd-list-request@lists.iem.at</a> wrote:<br>
>>>>>><br>
>>>>>> However, your description of the user/developer ratio doesn't ring<br>
>> true<br>
>>>> to<br>
>>>>>> me.  There's actually a surplus of developers and development<br>
>> energy-- I<br>
>>>>>> count two implementations of presets in the last year or two (in<br>
>>>> Pd-l2ork<br>
>>>>>> and the Chocolate et Coffee lib) which are in addition to however many<br>
>>>>>> already exist on svn and the Pd forum.<br>
>>>>>><br>
>>>>>><br>
>>>>>> --------<br>
>>>>>> Dan Wilcox<br>
>>>>>> @danomatika<br>
>>>>>> <a href="http://danomatika.com" target="_blank">danomatika.com</a><br>
>>>>>> <a href="http://robotcowboy.com" target="_blank">robotcowboy.com</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
>>>>>> UNSUBSCRIBE and account-management -><br>
>>>>>> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> N �n�r����)em�h�yhiם�w^��<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
>>>> UNSUBSCRIBE and account-management -><br>
>>>> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
>>>><br>
>><br>
</blockquote></div>