[PD] Updated pd-extended

[Ivica Bukvic]

True. It is trying to be to many things-- an ensemble and a software portal.
On Sep 23, 2014 12:04 PM, "Dan Wilcox" <danomatika at gmail.com> wrote:

> Yes, this is great news. I didn't mean to sound pessimistic earlier, just
> realistic.
>
> My 2cents, though is that the l2ork website is hard to navigate :D
>
> On Sep 23, 2014, at 11:54 AM, Ivica Bukvic <ico at vt.edu> wrote:
>
> Well, there is a concerted effort on the pd-l2ork side of things. We now
> technically have 3 devs contributing code regularly to git and 3 additional
> contributors.
> On Sep 23, 2014 11:14 AM, "Dan Wilcox" <danomatika at gmail.com> wrote:
>
>> I had to bring up semantics because "developer" means alot of different
>> things to alot of different people.
>>
>> Also, I didn't want to bring up vanilla versus non-vanilla, just pointing
>> out that the number of people who could help Hans put out a new version of
>> extended is rather low. IMO a languishing extended is bad news for Pd in
>> general as it's the go to distribution for most people using Pd ... but
>> that's probably for another debate. We all work on what's important to us,
>> I'm just sad again to see that the priorities don't seem to match up with a
>> concerted joint effort, at least as compared to my experience working with
>> OpenFrameworks. But of course what's considered a "concerted, joint effort"
>> is also up to interpretation :D
>>
>> Hopefully we'll have a development meet up at some point soon.
>>
>> I personally feel guilty seeing things like this come up because I have
>> the *ability* to do it, but I don't have the time when trying to balance
>> life, work, & art. Honestly, this is when I know I'm probably getting in
>> too deep ...
>>
>> This is why I suggested "graduate students". At this point, up keep and
>> versioning should be supported by some sort of institution, if possible,
>> and by people who could be rotated in and out.
>>
>> On Sep 23, 2014, at 10:57 AM, Ivica Bukvic <ico at vt.edu> 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
>>>
>>>
>> --------
>> Dan Wilcox
>> @danomatika
>> danomatika.com
>> robotcowboy.com
>>
>>
>>
>>
>>
>>
> --------
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140923/6356915c/attachment.html>