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" <[email protected]
<mailto:[email protected]>> 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, [email protected]
<mailto:[email protected]> 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>
_______________________________________________
[email protected] <mailto:[email protected]> 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)
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
