On Oct 8, 2011, at 4:29 AM, katja wrote:

On Sat, Oct 8, 2011 at 3:21 AM, Hans-Christoph Steiner hans@at.or.at wrote:

...

Unfortunately, the rest of the code is in a separate repo, and its svn. You can get SVN commit access by requesting it:

Oh yeah, sorry, forgot about that for a moment. Very inconvenient. Does it mean we have to work on the trunk of the svn repo? I'd need to study it's organization a bit more, it's confusing. There's a dir 'vanilla', where some of the core classes have been split out into standalones. For example, vd~ is a standalone but it's also defined in d_delay.c in pd-extended.git. I don't understand why it is all organized the way it is, and this makes me hesitant to request commit access as I could easily mess things up.

The organization is modular, so you can ignore the parts you don't want to think about. For example, if you asked to commit to 'externals/moonlib' that is a self-contained library project, so changes there won't mess up other libraries. For the most part, each folder in externals/ is a library. There are a couple folders that have libraries as subfolders, like iem/ or mrpeach/

And yes, vanilla/ is an experiment in splitting out the internals into a library. This allows people to write highly optimized versions of it for specific situations, like specific CPUs, and then use and distribute them easily.

For example, in the old pd-devel branch, there is a bunch of code that has hand-coded SIMD assembler. That would nice to split out into a vanilla-x86 library, which could be loaded instead of vanilla.

And don't forget, one of the beautiful things about SVN, git, etc. is that all old versions are still there in the history, so when things get messed up, which we all have done before and will do again, it is always possible to revert the changes.

.hc

----------------------------------------------------------------------------

The arc of history bends towards justice. - Dr. Martin Luther King, Jr.