[PD] libpd separating gui from core

Ivica Bukvic ico at vt.edu
Wed Feb 26 23:03:52 CET 2014


The reason why I believe combining all of these will not be feasible is
because in one of my recent conversations with Miller (and Miller please
correct me if I somehow misremember here) he expressed his belief any
project that exceeds N lines of code which I believe in this case it was
something like 10000, it becomes unmaintainable and dies. Supposedly
current pd codebase is at about 60 percent of that. That same code also
lacks a lot of basic facilities like infinite undo and other core tools
necessary for any kind of basic editing (given the nature of pd's structure
it needs to exist inside the engine itself that is also responsible for
stacking order). Features that have been added in pd-l2ork have added at
least a couple of thousand lines of code with the externals and everything
else obviously going well beyond that. As a result even if we prune the
code and make a libpd which again implies Miller is okay with that (as in
abandoning his version and building a new GUI app that interfaces with
libpd), it is unknown whether we are going to be able to remain under the
threshold required to meet Miller's goals. Personally I feel like Miller's
wisdom should not be taken lightly but at the same time I prefer to choose
the path of experimentation because it has proven so far very useful to me
and therefore I would prefer to continue to run with it knowing very well
that at some point in the future I just may hit a brick wall because I did
not listen to his advice. In other words I am taking that risk because
current benefits in my view far outweigh shortcomings and also because I
expect to learn a lot in the process which will make any potential dead end
look more like a crossroad. In my own work I simply do not have the luxury
of time required for pd/extended to catch up with even half of the features
that pd-l2ork currently offers. HTH
On Wed, Feb 26, 2014 at 2:58 PM, Rafael Vega <email.rafa at gmail.com> wrote:

> It's been fascinating for me to see what has happened with OpenFrameworks
>> and their "Do it with others" philosophy. It would be great if the Pd
>> community would migrate into something similar.
>>
>
What's interesting to me is that we had a similar issue in OpenFrameworks a
couple of years ago. As the community grew, more and more people wanted to
contribute but there was a lack of focus and the priorities of the project
were hidden by the core devs. We've had a couple of developer
conferences/meetups where decisions were made on how to best handle the
needs of the core people who started the project while opening up overall
development to capitalize on the experience of others outside of the core
group.

I must admit there were times where I wanted to fork OF or split off
development in some other way, but instead I decided to knuckle down and
see if we could work things out. I think it's worth a try in Pd. Even if it
takes a bunch of work up front, it will be worth it in the long run.

It's been an involved social process but, overall, we are moving ahead
quite well. There is a public roadmap, community action leaders (audio, 3d,
graphics, linux, etc), a robust forum, etc. GitHub has been amazing helpful
in this area is probably one of the main tools that makes this
collaboration possible.

There have been missteps and there are still issues to resolve, but we're
getting there. For instance, there will be a Documentation sprint at CMU in
a few weeks.

-- 
Dan Wilcox
danomatika.com
robotcowboy.com

_______________________________________________
Pd-list at iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140226/f4b1c374/attachment.htm>


More information about the Pd-list mailing list