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