[PD-dev] Refactoring Pure Data

[Vincent Lordier]

>
> So, supposing you want to work with Miller



Why no ?
As long as the developments are not made "under closed doors"  (= frequents
commits / test releases / bug submits ), I'm willing to work with anyone.

To me, I shouldn't have to "work with Miller" or "work with Mathieu" or
anything like this, simply because we are wasting way too much energy doing
theses diffs / merge stuff.
Having different branches is fine and even desirable (!), as long as it
leads to more generic modules that can be tested and refined in more diverse
cases.
We should be working on what we're good at and what interests us, and a
successful project is a project that's truly OPEN, and broken down into
workable / testable / improvable modules. And each of them could have their
own maintainer, structure or language even.
It works very well with externals. It doesn't (yet) with the internals of
Pure Data.

That implies a primary work on architecture and a cooperation of all devs
(commit often, criticize, propose, improve, test, submit patches, ...).
I'll develop on architecture on other posts soon, but I want to first focus
on making the best out of what we have today.

This said, I don't think Miller wants any help with that, but I'll let him
> tell you.


Miller ? ;)


> 'We've got to undo the MIDI revolution!  said Miller'
>
> This sentence is misleading. Pd doesn't undo the MIDI revolution, it goes
> beyond it. There's no going backwards here.



I do understand. Taking things apart is also going beyond what we have
today.
Let's face it : Pd is wonderful and mostly well written, but its code is a
little hairy (no offense intended).
And its development is slow, quite unpredictable and hard to read compared
to many other projects.
It deserves a clear roadmap, and a little of architecture work.
I think this work on architecture will be mandatory as we add new features
(like video~)


You could work on devel_0_39, but I doubt you can make any big changes. I
> once tried to remove unused variables from the code, and my change got
> reverted. Any change that doesn't bring a new feature is likely to be
> reverted, IMHO. This is both due to the diffing process used for
> submitting diffs to Miller and the diffing process used for merging new
> Miller releases into devel (supposing that there will ever be a
> devel_0_40... I don't know yet). Those are factors that encourage to keep
> devel_0_39 as close to Miller's as possible.



The solution isn't to make forks on forks IMO : the key is to reduce the
amount of code to be merged. Making Pd more modular allows to work on what
you want, remove what needs to be removed easily (if you need a small
footprint, have some other realtime constraints or implementation issues
like no FPU or loads of processor extensions), and leave the rest untouched.



> Why do you need to remove MIDI? Is it for code structure reasons or do you
> also have needs for that? (running Pd on very small computers...)



Exactly : making embedded Pd much easier. If all I need is just a few
filters, debounce, NN and OSC to drive an embedded device, and no GUI and a
small footprint, I could do it with Pd very easily : just upload a patch
into embedded Pd running on top of ucLinux and you're done.
Only today, it requires quite a bit of effort to make an embedded Pd.
PDa is a great initiative and we've seen this project ported on other
platforms like iPod, and someone on pd-list was asking about putting it on
his Archos. We will see more ports in a near future as embedded devices get
more exciting, accessible and hacked.
I want these ports to be smoother, so we could load a patch into a little
standalone device which only deals with sensors/actuators and network for
instance.


But having a simple, modular, readable code is useful to anyone.


> Again, my goal is not to alter pd in its behavior (yet),
>
> my goal is.


I think you've done much in showing how we could / should separate the GUI
from what I call the engine. It allows more flexibility, and as long as what
makes the strength of Pd isn't altered, it goes in the right direction in
terms of realtime behavior and creativity.
Because of the dev process, it takes a lot of energy.
Same goes with gg's PDa and Pd's possibilities in embedded environments, and
others I apologize for not mentioning.

I don't want to change its behavior in terms of features : splitting the
code into functionally coherent modules is "just" architecture & quality and
that's my goal.

> just to improve readability and separation of modules.

>
> Pd's style guide says that the one-or-two-letter prefixes on all the
> struct member names are there for "readability" purposes. That's not my
> kind of readability at all. What's your kind of readability? What does it
> mean to you?



- Self explanatory naming (how many single letters variables and / or funny
functions names do we have ?)
- Short functions (20 lines)
- Short files (100 to 200 lines)
- Reasonable Cyclomatic number
- A little indenting
- Getting rid of stuff.h which is a nonsense to me and having .h in modules
when required.


I went through a little static analysis and this is the start of my work.
Again, naming refers to architecture / modules, and that's where the work
needs to be done.
I think isolating Audio, MIDI, GUI, network, CoreLibs is a good, ambitious
but necessary start. It will make the development of Pd much faster, and the
overall quality of the code, thus the final executable will be improved.

It should be possible to replace the actual CoreLib with a pure integer one
if needed (see gg's port).
And if there's nothing else but "pure data" (!) to process
(sensor=>network), it should be possible to adapt Pd to do just this and do
it well.
This applies to any application you might think of.

Maybe Pd's internals architecture could be a nice topic for a little IRC
meeting ?
Who's in ?

> BUT my main problem right now is : on which version / branch should I
> > work on ?
>
> I wish you good luck in figuring that out.



thx :)


++

vincent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20060911/35d8b4a4/attachment.htm>