I understand that these 1-letter directory names are on purpose and are supposed to be cute, but it's really horrible idea. Yeah, explanation of these cryptic names is right there it the README, but it's still confusing if I'm just diving right into the source code to look around. And it serves nothing, as far as I can see. A tradeoff for nothing is kinda… weird.

EDIT: Ignore everything below. I fixed it.

I won't lie, the 1-letter top-level directories are mostly an indulgence of mine. I got the idea from some of the suckless projects, which use this method as well. It was confusing on their project (no documentation either on those), but it forced me to look into those directories and actually see what the code was doing. I could appreciate that code a whole lot more. I liked that concept a lot, and I hope people will do the same. I know it looks a bit daunting at first, but it's not that hard to get once you figure out what each folder is for (and there aren't that many).

That being said, I do intend to add at least 2 new directories to the top level eventually, and I know that's going to be confusing if they are all one letter.

Very lightweight, the whole thing downloads, compiles and runs almost instantly. After you go in the examples directory and run make, here's a little bash command to run and listen to each example in series while looking at its source:

  shopt -s extglob
  for f in ex_!(*.*); do ./$f; `play test.wav > /dev/null 2>&1 &`; less $f.c; done

ex_music is beautiful! But the source is not very expressive, even being familiar with DSP, a lot of the code has me guessing (well, it is expressive, but I guess the variable names are too short to my tastes).

Thank you for the kind words!

I intentionally made Soundpipe simple at the expense of being not expressive. Some day, I hope to build a language on top of Soundpipe that is expressive. It also is conceivable to embed Soundpipe into more expressive music languages like ChucK, Csound, and Supercollider.

Also, some of the DSP code is ported directly from Csound, which has some very hard to read code in there (sorry about that.)

This looks really interesting for web-based (emscripten-compiled) or mobile apps that need to keep their download size small.

An observation (not a critique): The LGPL3 license might be a problem for many MIT licensed game engines. If I understand the 'Combined Works' section of the LGPL3 right (I'm not a lawyer), it will not be possible to statically link an LGPL3 lib into a mixed-license project without providing a way for the user to rebuild the entire application from scratch, thus effectively polluting the more liberal licenses like MIT/FreeBSD?

On Ubuntu, you can try it out like so:

    sudo apt-get install libsndfile1 libsndfile1-dev
    git clone [email protected]:PaulBatchelor/Soundpipe.git && cd Soundpipe
    make
    cd e && make
    ./ex_music && xdg-open test.wav

btw, I just changed the "e" folder to "examples" for readability.

That line should read "cd examples && make".

I'm working on something similar. Though I have started in C++, I'm considering moving to plain C. It was nice seeing this here. Nice project.

Excuse my ignorance, but is this practical to use in real time embedded DSP analog hybrid systems like ±5v eurorack modules?

That would be really cool. A default compile of Soundpipe contains modules that only use libsndfile (95% of the code doesn't actually depend on this), c99 C and memset, malloc, and free from stdlib. I'd like to think that this opens up a possibility for embedded systems, but I really don't know.

I can tell you that have friends who sell commercial modules that run off a Raspberry Pi which use Csound and PD. I've tested Soundpipe on a Pi, and my initial tests show that Soundpipe can perform better or equal to Csound. So, if you're using some sort of embedded Linux system this is definitely conceivable.

How does this compare with SuperCollider / Overtone or CSound?

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.

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

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.

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

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.

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

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

"LongDescriptiveFilename.c"

  -- No C project ever

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

It looks like they took the CSound code and started porting it to "pure" C. (as opposed to definitions that are in the CSound language directly). I think this sort of stuff might be useful in a video game (maybe???) or someone who wants to make a sound-synthesizer GUI type application.

Looks like it actually implements quite a few opcodes from Csound. A quick glance makes it seem well suited toward quick integration in existing projects, with a very small footprint and codebase. Could be good for experimentation or learning low level DSP programming.

For realtime multi-voice synthesis, I keep using a not very well advertised side-project that performs reasonably well and also doesn't have a huge codebase: http://pippin.gimp.org/lyd/

That's the idea!

The next step is going to be building DSP code in Faust and putting them inside of SP.