<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So, supposing you want to work with Miller</blockquote><div><br><br>Why no ?<br>As long as the developments are not made "under closed doors" (= frequents commits / test releases / bug submits ), I'm willing to work with anyone.
<br><br>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.<br>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.
<br>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.
<br>It works very well with externals. It doesn't (yet) with the internals of Pure Data.<br><br>That implies a primary work on architecture and a cooperation of all devs (commit often, criticize, propose, improve, test, submit patches, ...).
<br>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.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This said, I don't think Miller wants any help with that, but I'll let him tell you.
</blockquote><div><br>Miller ? ;)<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 'We've got to undo the MIDI revolution! said Miller'
<br><br>This sentence is misleading. Pd doesn't undo the MIDI revolution, it goes<br>beyond it. There's no going backwards here.</blockquote><div><br><br>I do understand. Taking things apart is also going beyond what we have today.
<br>Let's face it : Pd is wonderful and mostly well written, but its code is a little hairy (no offense intended).<br>And its development is slow, quite unpredictable and hard to read compared to many other projects.<br>
It deserves a clear roadmap, and a little of architecture work.<br>I think this work on architecture will be mandatory as we add new features (like video~)<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You could work on devel_0_39, but I doubt you can make any big changes. I<br>once tried to remove unused variables from the code, and my change got<br>reverted. Any change that doesn't bring a new feature is likely to be
<br>
reverted, IMHO. This is both due to the diffing process used for<br>submitting diffs to Miller and the diffing process used for merging new<br>Miller releases into devel (supposing that there will ever be a<br>devel_0_40... I don't know yet). Those are factors that encourage to keep
<br>devel_0_39 as close to Miller's as possible.</blockquote><div><br><br>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.
<br><br> </div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Why do you need to remove MIDI? Is it for code structure reasons or do you<br>also have needs for that? (running Pd on very small computers...)
</blockquote><div><br><br>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.
<br>Only today, it requires quite a bit of effort to make an embedded Pd.<br>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.
<br>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.
<br><br><br></div>But having a simple, modular, readable code is useful to anyone.<br><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Again, my goal is not to alter pd in its behavior (yet),
<br><br>my goal is.</blockquote><div><br>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.
<br>Because of the dev process, it takes a lot of energy.<br>Same goes with gg's PDa and Pd's possibilities in embedded environments, and others I apologize for not mentioning.<br><br>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.
<br> </div>> just to improve readability and separation of modules.
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Pd's style guide says that the one-or-two-letter prefixes on all the<br>struct member names are there for "readability" purposes. That's not my
<br>kind of readability at all. What's your kind of readability? What does it<br>mean to you?</blockquote><div><br><br>- Self explanatory naming (how many single letters variables and / or funny functions names do we have ?)
<br>- Short functions (20 lines)<br>- Short files (100 to 200 lines)<br>- Reasonable Cyclomatic number<br>- A little indenting<br>- Getting rid of stuff.h which is a nonsense to me and having .h in modules when required.
<br><br><br></div>
I went through a little static analysis and this is the start of my work.<br>Again, naming refers to architecture / modules, and that's where the work needs to be done.<br>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.
<br><br>It should be possible to replace the actual CoreLib with a pure integer one if needed (see gg's port).<br>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.
<br>This applies to any application you might think of.<br><br>Maybe Pd's internals architecture could be a nice topic for a little IRC meeting ?<br>Who's in ?<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> BUT my main problem right now is : on which version / branch should I<br>> work on ?
<br><br>I wish you good luck in figuring that out.</blockquote><div><br> </div>thx :)<br><br><br></div>++<br><br>vincent<br>