[PD] Updated pd-extended

Phil Stone pkstone at ucdavis.edu
Tue Sep 23 19:07:03 CEST 2014


It is excellent news that pd-l2ork may soon be available outside of 
Linux, Ivica. Cheers, and best of luck on this tack.


Phil


On 9/23/14, 7:57 AM, 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 
> <mailto: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
>     <mailto: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 <http://danomatika.com>
>     robotcowboy.com <http://robotcowboy.com>
>
>
>
>
>
>
>     _______________________________________________
>     Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
>     UNSUBSCRIBE and account-management ->
>     http://lists.puredata.info/listinfo/pd-list
>


-- 
Phil Stone
Programmer - Application Development Team
Information Technology
UC Davis School of Veterinary Medicine
530-752-5282 (o)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140923/97656dd5/attachment.html>


More information about the Pd-list mailing list