I always liked the idea of coding music. Programmatically making some awesome tracks. Then open source it and let people run it on what ever they want.
It wasn't exactly a hit, but then again promotion is the hard part. I'm finishing a lengthy write-up on the process, which focuses more on harmony (specifically freestyle just intonation) rather than programming. I believe the programming portion is highly personal, so it's more interesting to share general composition techniques that apply well to algorithmic music.
Executable music is also an established genre in the demoscene, but the music is typically written in trackers rather than with code. The extremely small intro categories do have fully algorithmic music, which can be really inspiring. That said the size limit often forces the sound into a "bytebeat" style, so I'd say size-unrestricted algorithmic music ends up being a rare genre that's not even found in the demoscene (as far as I know! I'd love to find more music like this).
Yeah I normally don't make any music, but I really like glicol. A while ago the author of glicol 'shilled' it on HN, and I was really blown away by the demo tracks, for example:
Using the addition operator for manipulation is a bit unusual. Why did you choose it? I don't have R studio or anything on my computer, so I can't test it, but do things like
In base R, `+` is the usual arithmetic operator for numeric and complex vectors. I'm not a super R expert but I'm pretty sure the addition operator is overloaded here. It simply means:
Edit. Found the definition in the source [1]. I think the approach is similar to Go's approach to method definition [2]. Methods are defined on types, i.e., methods are functions with special receiver arguments. The infix notation instead of prefix notation is just syntactic sugar.
In creating a music score, you literally "add" components to the score. So it's natural to implement this operation this way. From the OOP perspective, it's just method overloading. Not uncommon in R development.
This is quite idiomatic for R; packages like ggplot do the same thing to, for instance, build up graphics- see https://r4ds.hadley.nz/data-visualize for some nice examples
ggplot2 is pretty much an exception at this point, and if the package was created today it would use the pipe instead of add [1]. Most packages use pipes now (especially with the introduction of the pipe operator in R 4.1.0).
I am no R expert, but pipes don't seem the most intuitive for ggplot. This is because they would imply that, e.g., ggtitle() %>% geom_point() means that ggtitle() outputs an input for geom_point().
Found it in profile area of https://github.com/flujoo .
HN post of his other work ch0p1n in 2022: https://news.ycombinator.com/item?id=30321645