[zebproj]

Hi! I'm the creator of SoundPipe.

Soundpipe is more low level than SuperCollider/Overtone than Csound since it's just a C library and not a music language. You could certainly build parser on top of Soundpipe that can look like SuperCollider or Csound (I'm planning on doing just that in the future.)

SoundPipe borrows a lot of code from Csound opcodes, so one could arguably say that it "sounds" like Csound.

[ubercore]

I'm curious, why just "e", "m", "h", "t" for source directories?

[zebproj]

Aesthetics, mostly. But it also is a visual reminder not to over-complicate things unless I really need to. I got the idea from reading some source code from the suckless.org guys.

I meant to document the directory structure here:

(h)eaders, (m)odules, (e)xamples, (t)ests.

Arguably obfuscated, but I think with only 4 directories, it's still manageable.

[ubercore]

Maybe if _really_ thoroughly documented, but for n=1, I found it off-putting.

[zebproj]

Yup. Documentation is in the works, I promise! For Soundpipe AND each individual module. I'm planning on HTML documentation as well as man page documentation.

In the meantime, I think most of Soundpipe can be grasped by looking at a few examples as well as m/base.c and m/base.h.

[to3m]

At one letter per folder, it's not like there's much to remember :)

(I don't think it's much worse than calling your header file .h rather than .header, and it saves a bit of typing/tabbing. But I'm only one person too.)

[zebproj]

The way I see it: it's only four folders, and the letters correspond to what they do. My brain can handle this.

[alkonaut]

"LongDescriptiveFilename.c"

  -- No C project ever

[vonmoltke]

Actually, the one big C-based project I have worked on had many long, descriptive names. It also had names that were acronym soup. :P