[blubb-fish]

interesting that you come forward with music resulting from this approach as not being very rewarding. but why is that so? I'm not a musician, so maybe I'm naive - but shouldn't music programming be able to produce anything and beyond?

[hsartoris]

I have a much longer comment above that addresses your point, I think. The gist is this: programming music, as compared to using a graphical DAW, is highly tedious. Unless you know exactly what you want, down to the note, writing music in code would take far longer to produce results.

[TheOtherHobbes]

I've been thinking about the differences a lot, and the basic problem is a misunderstanding of what music is.

To a coder, music looks like a sequence of instructions that make sounds, so of course it's natural to assume that it's just like code. Music is a series of events, so let's write code that makes a series of events. How hard can it be?

To a musician, music is tactile, improvisatory, and sculpted. It's nothing like code. At all.

Even if you're using a DAW with a mouse, you're still shifting elements around in time and sculpting fine nuances of the the sound with controller curves.

So code is a terrible UI for music, and live code is even worse. You have to spend so much time on irrelevant distractions - creating buffers, managing objects, iterating through arrays - that there's almost no connection left between the sounds that are being made and your expressive intent.

So live coding only works if your expressive intent is trite and lacking nuance and depth. The only people who do it are hobby coders and a small community of academics who are trying to sell it as a valid revolutionary activity.

Interestingly trackers, which are by far the most successful coding environment for music, also have the lowest conceptual overhead.

[blubb-fish]

interesting point