[blubb-fish]

i am very excited by the idea to create music by means of programming. but it seems that there isn't even a single project with an active community. supercollider seems to be the most popular with regard to GitHub stats. Sonic pi seems to be the most recent endeavor in this area. but it doesn't offer any deb-packages. compiling for Debian/Ubuntu seems to be not documented.

my impression is that this is coming up every couple of years but nobody so far succeeded at actually producing a system that gains meaningful popularity. not to mention how difficult it was too compile/set up the software for the various projects i have tried.

another problem is that very few YouTube tutorials showcase rythms and melodies going beyond something resembling a ping pong match on speed.

would love to hear your opinion.

[hsartoris]

I think the relative lack of a strong community around programmable music generation probably originates from a lack of a particularly good use case. To me, as both a programmer and an electronic music producer, applications like Sonic Pi and Supercollider are not all that appealing, and actually come off as downright tedious.

First of all, music creation is too chaotic a process to allow for simply getting things right on the first try. Single notes in arpeggios are changed, entire progressions are taken up and down steps, parameters are continuously played with until you find the right levels, and all of these and more are much better suited to graphical abstraction purely for ease of use. I'd much rather spin a virtual knob to find appropriate levels than type and re-type a variable quantity, especially if I have to wait for that quantity to update every time.

Second, music is all about edge cases. Using control flows to automatically change a piece is nice, but not as nice as quickly rearranging tracks in a visual playlist. Deciding that a particular loop should end in a different way is simple in a visual editor: cut off the tail and put something else in, or make one instance of the loop separate from the others and edit in place. These are processes that take less than a second for me, but would involve careful crafting of conditionals to achieve in Sonic Pi or the like.

All of that said, I think this approach probably has its merits. I've been wishing for scripting in DAWs for a long time, and having a synthesizer that supports writing code to modify waveforms or change how parameters link would be awesome (if this exists, someone please tell me). Projects like Sonic Pi, though, seem to take this past the point of usability.

[rainbowmverse]

>> "I've been wishing for scripting in DAWs for a long time, and having a synthesizer that supports writing code to modify waveforms or change how parameters link would be awesome (if this exists, someone please tell me). Projects like Sonic Pi, though, seem to take this past the point of usability."

Reaper has a scripting language. It even comes with a few synths written in it, complete with source.

I want a DAW with the flexibility of Reaper and the UX of Ableton.

[dbattaglia]

If you spring for the full Max4Live Ableton package, you can automate quite a lot via the maxmsp JavaScript object, which gives you scripting access to the Live environment vis the LiveAPI object. It’s kind of an awkward API to use but still much nicer than using the traditional graphical max objects.

https://docs.cycling74.com/max5/vignettes/js/jsliveapi.html

[rainbowmverse]

I'll keep this in mind for when I can afford a version of Live that supports this.

[seandougall]

Have you checked out Max for Live (https://www.ableton.com/en/live/max-for-live/)? I hear good things about it, second-hand.

[NihilumExNil]

While I completely agree with the sentiment, I still wonder what's the difference to graphics. Is drawing easier, for lack of a better word, than gfx-programming? I would argue this comparison is apt and yours falls flat. B flat.

For starters, you could have a skeleton of a script with accessible parameters, given knobs. That would look like a DAW, except for text instead of pseudo design with screws and LCDs that mimic real objects (skeumorphic). Yes, you want buttons, visual programming still sucks. Demo coders like Farbrausch program their own demo tools, eg. Werkkzeug 3, for exactly that reason, isn't it? Considering gfx programming as the comparison, of course textures, models and so on are modeled in an analogue fashion. Nobody programs a human.md3 to evolve from an embryo for fun, but in principle, somewhen it could be done. Music is a lot like vector graphic art, you can do a whole lot with simple shapes and gradients. And you can program complicated sound effects perhaps easier than as a 5 second loop rendered to wav and pitched by the DAW, if you know what I mean.

Note composition as you remark is especially besides the point. The drone noise perspective might be an extremely misleading example, but music programming should be able to paint outside the classical frame. It should allow to define sweet points of resonance, instead of chasing harmony by ear. This does require deep understanding, so instead I'm happy with finger painting ... because it's so close to the metal, err, paper.

It's very sad because I have no idea of the potential. Composition to me is choosing an instrument and arbitrating simple known melodies to complexer ones until it sounds harmonious thanks to obeying the circle of fifths, but that's mostly it and mostly rather superficial, which doesn't matter as long as the instruments sounds niceand if it doesn't I'll split the melody by octaves e.g. and choose two different instruments, alter the octaves to get a high contrast (shout out to my man). Because of the loop nature of pattern based composition, I am mostly not interested in arrangement. This again compares to shader programming. And even big studios basically just stitch together single scenes. ... yadda yadda yadda.

You might also compare the violin to the voice. Far more people can or think they could sing. Making the violin sing is just much more complicated, but not exactly boring.

[jcelerier]

> I've been wishing for scripting in DAWs for a long time, and having a synthesizer that supports writing code to modify waveforms or change how parameters link would be awesome (if this exists, someone please tell me).

I'm working on a DAW that you can live-code with JS and math expressions if you're interested: https://ossia.io

C++ just-in-time compilation of sound effects is coming in the few next months (JS just does not cut it for real-time audio with per-sample access).

[ckocagil]

There's also Tidal: https://tidalcycles.org/

Here's a live coding video from its front page: https://www.youtube.com/watch?list=PLybSFICi4UliK17U6rxPneXA...

[TheOtherHobbes]

Music coding is conceptually challenging, which immediately limits the community of interest to people who like coding for its own sake, and not usually very rewarding musically, which limits the community further to academics, students who are forced to experiment with code (usually briefly), and the odd hobby experimentalist.

Given all the other tools available, from DAWS to trackers to VSTs to hardware synths, why would a musician - as opposed to a coder - want to climb the incredibly steep learning curve?

[empath75]

Music production with ableton and the like is programming. All the synths and effects are functions operating on a signal and the various knobs and sliders control parameters.

[TheOtherHobbes]

Not to a creative musician.

There should be a special name for this fallacy, because it occurs so often on HN.

Just because a domain looks a bit like a trivial mathematical operation to mathematically inclined outsiders doesn't mean that the math really is trivial, or even that the real core of the domain is best summarised as a trivial mapping.

[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

[merongivian]

Yea thats a problem for all of the most popular livecoding libs (tidal and sonic pi depend on supercollider). One alternative is to use js (gibber.js) and doing livecoding in the browser. I've been playing with the idea of creating this lib that uses ruby and compiles to js under the hood: https://github.com/merongivian/negasonic, one drawback is performance though

[jtms]

Having tried both Gibber.js and Tone.js I would give the edge to Tone.js - less crackles and pops and generally more a more stable bridge to the Web Audio Api. Give it a look if you like.

[merongivian]

yes, Im actually using Tone.js for my library, indeed is great but still, is web audio api (everything sounds like gameboy or snes :)), its fun though

[rollcat]

> Sonic pi seems to be the most recent endeavor in this area. but it doesn't offer any deb-packages. compiling for Debian/Ubuntu seems to be not documented.

You sure?

    % lsb_release -sic
    Debian
    stretch
    % apt-cache madison sonic-pi
      sonic-pi | 2.10.0~repack-2 | https://deb.debian.org/debian stretch/main amd64 Packages
      sonic-pi | 2.10.0~repack-2 | https://deb.debian.org/debian stretch/main Sources