<p dir="ltr">Based on what metrics?</p>
<div class="gmail_quote">On Sep 25, 2014 11:05 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>
For libraries, there is binary compatibility between pd vanilla, extended,<br>
desiredata, and vibrez.  desiredata made much larger changes to the 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 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>> 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 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 don't<br>
>>> care that much about titles. Yet, I would argue that as far as low 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 also<br>
>>> argue it is essential and offers a slew of features that are 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 the<br>
>>> lack of manpower. But that is about to change once we complete port to 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 to<br>
>> do<br>
>>> this again. Once this is done, we won't have to circumnavigate 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 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 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 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 true<br>
>> to<br>
>>>> me.  There's actually a surplus of developers and development 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>
</blockquote></div>