[PD] libpd separating gui from core

Rich E reakinator at gmail.com
Thu Feb 27 04:18:27 CET 2014


On Wed, Feb 26, 2014 at 5:03 PM, Ivica Bukvic <ico at vt.edu> wrote:

> 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.
>

Refactoring usually *reduces* code length, but the key to staying in sync
with vanilla (and all projects that use it) is to refactor in small chunks,
keeping the modifications focused.

For instance, it seems like there are two main concerns floating around:

a) multiple instances of pd
b) separating GUI from core

There are other suggestions like platform-specific vectorization and
multi-threaded support, but if you try to do these at the same time, you
reduce the chance of ever getting the code back into vanilla.  They can be
taken on after.

IMO, the best thing to do going forward for a) would be to sync up with
Miller and what he netted out with last time this was discussed ( see
thread: http://lists.puredata.info/pipermail/pd-dev/2013-12/019702.html).
It seemed like he was proposing to take a hefty chunk of the work on, or
maybe if he is confident in merely the approach, someone else can have a go
at it.

For b) it seems like no one really knows fully what is entailed, maybe it
is something that just needs to be tried as a throw away first, with say a
minimal GUI in something other than tk as proof of concept.

Corollary about multi-instances and multi-thread support: while I agree
thinking about them together can be useful, I think the former will only
make the latter easier to take on afterwards.  The smaller the changes, the
easier it is to verify backwards compatibilty, and to accept into vanilla.

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)
>

I don't think anyone wants this, my understanding is that the goal is to
make it where libpd does even less, by first isolating pd-core and its
memory usage.

cheers,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140226/1fad89a6/attachment-0001.htm>


More information about the Pd-list mailing list