Étude in C minor (2020)

Étude in C minor (2020)(zserge.com)

78 points by etrvic 194 days ago | 15 comments

ofalkaed 187 days ago |

Back around the turn of the century my wifi card died when I was reinstalling my system and I had no money for a new wifi card, no internet at home so I ended up with a very a basic console only Arch install, only audio software I had installed was SoX. I started out using SoX and Bash to make music, explored Lame's ability to encode anything as an mp3 and eventually discovered what TFA talks about. I never made anything I would call good, it just is not a method all that compatible with my interests but it has stuck with me all these years and has left me feeling that much of computer music has stagnated (in method, not output) and we have a great deal of room to explore yet.

Stagnated is not quite the right word, I think what computer music has been doing in the last couple decades is establish its primary instruments and techniques, the various audio DSLs, which is a fairly important thing musically speaking, it builds the culture and repertoire. Computer music is strongly rooted in how the musician interacts with the code, it is the strings of their guitar and I think we have barely touched on exploring that relationship yet. What is the prepared piano of computer music? how do I stick a matchbook between the strings of the code or weave a piece of yarn through it?

I hope more go back to exploring these very basic and simple ways of generating sound with computers and start experimenting with it, there is more out there than just ugens.

iberator 187 days ago | |

Hehe. You should check out AX.25 protocol over sound card. Its basically internet packets over radio or audio.

HAM RADIO stuff

bovermyer 187 days ago |

If you tell me about sound, and describe sound, and speculate about sound... give me sound.

It's a small thing. But if you're going to say you have something to say about sound, give me some sound to demonstrate your point.

dullcrisp 187 days ago | |

Did you run the code samples?

p0w3n3d 187 days ago |

I got this knowledge really too late, but recently I've learned how the music is (was?) made on old computers like Atari 65XE or NES (the same processor 6502). The amount of work specified in the article above, is increased by the calculation of vsync of the monitor used, and correlating it with the sound frequency. This leads for example to the same game playing in different tonation on PAL and NTSC. Today it's already obsolete, but the emulator still has to be emulating the one or the other standard, to comply with the code. Today we have great privilege to abstract the sound from the monitor sync (by OS) but this is not the case in some embedded devices.

dang 187 days ago |

Discussed at the time:

How to create minimal music with code in any programming language - https://news.ycombinator.com/item?id=24940624 - Oct 2020 (78 comments)

ta2112 187 days ago |

> that’s why CD music had a sample rate of 22000 Hz. Modern sound cards however tend to use sampling rates twice as high - 44100 Hz or 48000 Hz or even 96000 Hz.

Not exactly the point of the article, but this is all sort of wrong. CDs use a sample rate of 44.1 kHz per channel, not 22 kHz. I'd hazard this cuts down on rounding errors from having only one sample per 22kHz range. DAT used 48 kHz I believe to align evenly with film's 24 frames per second. 96 kHz is commonly used for audio today, and the additional accuracy is useful when editing samples without producing dithering artifacts within human hearing range.

NobodyNada 187 days ago | |

CDs use 44.1kHz because your sample rate needs to be double the highest frequency you want to encode to avoid aliasing artifacts: https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampli...

20kHz is the top of the human hearing range, and picking something a little bit higher than 40kHz gives you room to smoothly roll off frequencies above the audible range without needing an extremely steep filter that would create a large phase shift.

TheOtherHobbes 187 days ago | | |

You do in fact need an extremely steep filter. 44.1kHz is a little over an octave above 20k, and for adequate filtering and reconstruction you need 96dB of roll-off at at 16-bits and 144dB at 24-bits.

It's practically impossible to design an artefact-free filter with a roll-off as steep as that. Every single person who says that 44.1k is enough "because Nyquist" has failed to understand this.

You can trade off delay against various artefacts, including passband ripple, non-linear phase smearing, and others. But the shorter the delay, the less true it is that you get out exactly what you put in.

o11c 187 days ago | | |

In practice, artifacts become common past something like 16 kHz. I'm not sure how much of this is math and how much is that almost all speakers are made very cheaply.

kevin_thibedeau 187 days ago | |

44.1 was selected because it was a viable rate for recording on both PAL and NTSC video recorders gently modified to capture digital audio on tapes that were sent out to the mastering plants. There is nothing otherwise special about it.

felineflock 187 days ago |

Bytebeat is kinda cool:

https://dollchan.net/bytebeat/#4AAAA+kUli10OgjAQhK/Ci3R3XXTb...

olivierestsage 187 days ago |

I realize this question goes against the point of the article, but: What specialized tools/languages are people currently using in this space? Every time I go down this rabbit hole, I wind up hesitating forever between Csound, Supercollider, etc.

aappleby 187 days ago |

no audio sample on the webpage?

macintux 187 days ago |

(2020)