Hacker News Reader

Comment by lynndylanhurley | Hacker News Reader

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.

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.

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.

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

That's the idea!

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

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/

Reply on news.ycombinator.com