zebproj

I'm currently taking a class taught by the creator of Chuck, Ge Wang. Great guy. He always tells people that Chuck "crashes equally on every platform".

I find ChucK to be a pretty easy language to get into. It lends itself really well for algorithmic composition and live coding. I have quite a bit of fun with it!

A big downside to ChucK is that it has a very limited set of unit-generators for sound, and it's very hard to do any sophisticated synthesis and sound design. That being said, it's pretty easy to build third party chuck plugins (called "chugins"). I really like working with Csound, so I built a Csound chugin: https://github.com/PaulBatchelor/ChuckSound

What exactly is a "rubber band"?

I got a lot of inspiration from forthsalon.

It was only after I built Sporth that I realized how expressive a Forth can be for creative coding.

I'm actually the creator of soundPipe, so it makes sense that you probably haven't heard of it.

Sporth is definitely a language for people with experience with modular synthesis and digital signal processing. People with experience in SC or Csound should feel pretty comfortable (in fact, many Sporth modules utilize algorithms taken directly from Csound opcodes)

Soundpipe is a library which takes a very modular approach as well (sporth is a language built on top of SoundPipe).

I know the AK guys quite well, and we're actually working together to get Soundpipe working with it.

People interested in how MUSIC-N languages work should look at Csound, which is a direct descendent of the MUSIC-V language. Their syntax is very similar, and many MUSIC-N files have been ported to Csound.

> Where I see the real potential is using the native language of DAWs (digital audio workstation) like Protools, Ableton, and leveraging their native languages to write new scripts and library extensions for hardware.

Most of these DAWs are written in C/C++. In many cases, things are really closed down (looking at you ProTools), so its difficult/impossible to write extensions unless you intend to sell it commercially.

Renoise has a pretty good API in Lua for building plugins, which I thought was kind of neat.

Ableton has Max4Live which I think counts for an extension language.

As far as "native" code goes, I've been working a library of high quality DSP modules that you can use to build plugins called Soundpipe:

http://www.github.com/PaulBatchelor/Soundpipe.git

Several months ago, I compared musical languages, writing essentially the same thing in each one:

https://www.safaribooksonline.com/blog/2014/11/07/making-com...

I also wrote one myself:

http://paulbatchelor.github.io/proj/sporth

Not going to lie, this seems like a terrible language for musicians to compose in. Maybe I need time to get used to it, but it looks more like an esoteric programming language to me. The amount of brackets needed for it to work is just begging for typos.

Furthermore, the syntax doesn't feel "readable" like a music score. The symbolic notation doesn't click for me. I'd like to be able to hear what is going on in my head, and this just doesn't seem designed for that. By contrast, Alda (a musical language posted yesterday) is very readable to me as a musician. ABC notation and Lilypond were very good sources of inspiration.

There are some things I like about Skoar. The use of a really good audio engine to produce the sound wins in my book (there doesn't seem to be any obvious way to control the sound itself, though.) I think the way you express dynamics using hashes is pretty novel. (May want to consider using decibel scaling instead of linear scaling.) I like the fact that you have incorporated programming elements like conditionals, loops, and variables.

Both Alda and Skoar basically focus on conventional western music notation, which is perhaps the most boring part of computer generated music. Sound design plays much greater importance, and it makes me sad to see no focus on that whatsoever (Sound is uh... the part that actually makes the music).

I'm hesitant to share this on HN because it's not done yet, but I too, made yet another musical language:

http://paulbatchelor.github.io/proj/sporth

Here's the code:

https://github.com/paulbatchelor/sporth

And here's what it can sound like (everything minus the outdoor ambient sample is synthesized in Sporth):

https://soundcloud.com/thebatchelorlab/scheale

Supercollider is a popular choice! If you're interesting more of a survey, I wrote a blog post a few months ago where I compared music languages by writing the same sound in each one:

https://www.safaribooksonline.com/blog/2014/11/07/making-com...

Alda does MIDI out, so you could probably route Alda to PD (PD is really good at handling MIDI signals).

While not graphical like PD, several musical languages make a distinction between the sound design (signal flow and modules) and events (notes, etc).

Csound is the first to come to mind, with it's MUSIC N orchestra + score paradigm. The orchestra syntax (especially the new changes in csound6) lends itself nicely to expressive sound design. Scores, however, are tedious to write by hand. Most Csounders opt to generate these using another program (which in itself is pretty cool, IMO)

ChucK does a similar thing as well, where you can write the signal chain (oscillator => filter => dac) and then you can control it using ChucK's C-like syntax. If you are interested in algorithmic composition and have a stronger background in programming, this is a pretty fun language to work in. That being said, Csound has a much better collection of sound modules.

Not exactly the answer you were looking for, but I hope you can check them both out, as they offer different approaches to computer music composition.

I've had a lot of experience with various musical languages (ChucK, Csound, Supercollider, Max/MSP, PD, Faust etc.) I've even designed a few music languages for myself. For what it's worth, I did go to a music school and graduated with a bachelors degree in music, with a strong focus in computer music composition.

In the case of Alda, I'm a little underwhelmed. To be fair, it seems that the author of this software has done a good job meeting his goals. The syntax does look quite intuitive, basing it off of Lilypond syntax was a good choice IMO. I wouldn't call it a programming lanuage, and it can't do everything I want, but it seems to fit certain types of music quite well. Here is my big issue:

>In the near future, Alda’s scope will be expanded to include sounds synthesized from basic waveforms, samples loaded from sound files, and perhaps other forms of synthesis.

I don't want to say Alda sounds "bad", because soundfonts, samples, and basic waveforms have their place for certain styles of music, but it is certainly quite limiting. Considering that there are massive books written about the "perhaps other forms of synthesis", it doesn't seem like sound itself to be too big a focus.

From what I'm reading, Alda is essentially a MIDI file generator. It doesn't actually produce music, rather, it sends MIDI instructions for how to play music somewhere and leaves it up some other program to make the sounds. All of the other music languages I've mentioned can actually make music internally.

Have you ever considered using other music languages with Alda. Overtone is just Supercollider + Clojure, so I'm sure you do something similar. I imagine it would be pretty trivial to get Alda to write a Csound score, since it's basically just a text table. PD has libpd, which I've had limited success with. I might as well mention my project Soundpipe as a possible DSP engine as well: www.github.com/PaulBatchelor/Soundpipe.git

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

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

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.

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

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.

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.

That's the idea!

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

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.

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.