True. It is trying to be to many things-- an ensemble and a software portal. On Sep 23, 2014 12:04 PM, "Dan Wilcox" <danomat...@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 <i...@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" <danomat...@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 <i...@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" <danomat...@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-requ...@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@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 > > > > > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list