The folder structure is such a mess that I thought it only does midi but I used the search bar and was amazed by the crisp SID rendition. Should add a filter toggle to remove all the midi spam.
Nice! Love the huge library, I wonder how much time was put into compiling it.
Reminds me of a Chiptune player I made a wile ago (with Chiptune.js), but with only like 20 predefined Cracktros. If anyone is interested: kleemans.ch/static/chiptune
I don't know much about the MIDI format, but there was one song [1] that I used to love listening to on Windows 9x. I guess the file took advantage of some 9x quirk, because the orchestration is completely busted in modern Windows and macOS. I'm so happy because this site plays it just the way I remember it!
MIDI has no sound on its own, so it depends on the thing playing it. Windows' MIDI synthesis might have gotten worse, or you remember it on the particular sound card you had with 9x.
What a good demo! Yeah, I think I has to do with "updated" MIDI synthesis logic. The issue involves some of the harmonies; on modern devices, they start but never stop, then begin to layer on top of themselves, making it a total cacophony haha.
Try the settings in the player, it has loads of soundfonts to try, they all sound very different. If it's a midi file, it all depends on what sound card or installed soundfont you had at that time.
But the site already has tons of tracker music, as well as other not-strictly-chiptunes like an incredible number of .mid versions of classical music and contemporary pop songs of all things.
I know, but I don't understand your point. The site is full of .mids and mods, as well as other mod-like formats ripped from various devices. I'm not even sure if it does have any actual chiptunes, as in synthetized in realtime!
You wrote that you find it a «strange omission» not to have included SID tunes in a collection of «mids and mods». Well, simply, the coder must have had an engine capable of playing the latter, which is simple - and not an engine capable of playing the former, which is complex.
May I recommand to you the High Voltage Sid Collection? It is a collection of curated SID songs in a neat package, and it is updated regularly!
https://www.hvsc.c64.org/
In the scene people always set SIDs and tracker chiptunes apart, because of how technically different the two are. There's an enormous technical complexity of having to emulate not just the SID chip (which still isn't 100% understood) but also the 6510 CPU and even some of the C64's CIA timers to accurately replay SIDs, whereas almost all sample-based tracker music from the Amiga and PC need none of that effort. Replaying SIDs is even more complicated than emulating e.g. SPC700 of the SNES, the PSG sound of the SMS, or the YM/OPN2 synthesizer of the MegaDrive.
> also the 6510 CPU and even some of the C64's CIA timers
yes, but also the VIC timers and the PLA. So basically you need all of the c64 chips emulated, at least in part :)
I wrote a simple SID player for fun and I feel like it's 20% shy of being a full c64 emulator, all it needs is video output and keyboard/joystick input.
I have a physical SID chip and I was looking at implementations of players and ... was shocked at how complicated they are. I guess it makes sense though: SID files are tiny because they are in effect full C64 native programs that generate music. It would be hard to do otherwise on that platform.
I wrote a simple program that transformed basic (60hz, no PCM-style hacks) SID programs to like sequence of byte instructions for the SID chip so that I could replay without emulating and the file sizes are massive compared to the original!
Here is an awesome single file SID player written in C,
Oh, wow! Such a compact cpu routine! Thanks for the link.
I wrote mine in C too and it's basically a 1k line switch statement for every 6510
instruction :) I went the extra mile and made it cycle-accurate though.
libsidplayfp is probably the best emulator out there. It actually emulates voltage levels at one stage. The wiki has a bunch of info on SID reverse engineered from die shots https://github.com/libsidplayfp/SID_schematics/wiki
Sample based tracker formats shouldn't be considered chiptunes. The latter is supposed to mean sound generated by dedicated hardware with automatic waveform generation, envelopes, and filtering. Doing it all in software by mixing samples isn't the same.
Sample-based tracker music and the Amiga scene is where the term and the artistic style was born. The Amiga scene and the musicians of that era are the authority.
The term chiptune, and the technical approach and associated musical character, was firmly cemented in the Amiga scene already in the first half of the 90s. The composer who coined the term (in the beginning of the 90s) was legendary computer musician Matt "4-Mat" Simmonds. Everyone understands the difference between oscillators and sample playback, but notwithstanding the term being "technically lopsided" this is still the history of it.
To be fair, nobody called c64 music "chip music", it was just "music/tunes" because c64 music is really just code so in a way all of it was chip music (excepting some digi tunes).
The term chip music was coined on amigas and newer computers to differentiate it from regular sample based music.
Now you get an entire thread of nerds explain you the etymological history of sound chips and the huge differences between a sid program and the mid format despite having perfectly working converters in both directions.
It’s important to be mindful that the engineering is a minority slice of all the decisions that go into a product’s development.
The reason why some engineers need to be managed by Product and Project is that they don’t think hard about all the constraints, such as the cost of developing multiple native apps vs. the benefit that would provide.
This is often due to a failure of empathy: many engineers envision the common user being like them, when really the common user doesn’t know, notice, or care about whatever this “Electron” thing is.
I’ve seen, time and time again, developers having loud opinions about how choosing X over Y is because people are dumb, or cheap, or inexperienced. Those are all possible, but not nearly as common as they think. They’re easy explanations. But I rarely see developers do the engineering part where they quantify the issue and make a case for picking X over Y.
If developers hate Electron so much, the answer is to develop the skill set for making an informed argument that isn’t limited to just things like RAM and latency and file size. These often aren’t compelling business reasons. They’ll either learn more about why Electron gets picked, or they’ll have a solid case to make for why not to pick it.
I'm on a four-person team building a React Native app. RN is awful, I'll admit, but it would be impossible to work at the pace we do if we were maintaining fully parallel Android and iOS codebases.
Besides, it's the hardware's job to optimize for the capabilities of the SDK.
I was with you for the first paragraph. But that's just despicable thinking:
> Besides, it's the hardware's job to optimize for the capabilities of the SDK.
You can't possibly blame the hardware manufacturers for how poorly React Native runs. Even if the CPU engineers wanted to target React specifically and make it run better somehow (and you seem to think they should), where would they begin? React sits on top of 35 layers of software abstraction and runs in 2-3 virtual machines, how could they target RN?
Assuming they could add magical instructions that benefit React somehow, who's going to patch the 34 lower layers for React to benefit from it? The manufacturers? The React team? You?
I don't have any performance issues with React Native[0], so as far as I'm aware the status quo is fine with regards to how well the hardware is optimized for the SDK. The specific SDK I'm referring to is JSCore, obviously everything on top of that is third-party.
[0] My main beef with React Native is the total lack of useful stack traces. Also, when running on a device, when you tap Debug before manually setting your dev machine's IP, the app is bricked and you have to delete and reinstall it.
This is why you need to become king. In many places, it is the only way to truly deal with this nonsense. Top-down.
If you want a big org to defenestrate electron, your #1 mission is to generate a very scary narrative that electron is a 'legacy' technology and that your competition is already 2 steps ahead. You could spin little lies like "I overheard a member of KPMG discussing our competition's use of SSR and native local apps to deliver leading-edge UX while at lunch last week".
The super shitty thing about electron is that it does, arguably, reduce the overall complexity of delivering an end solution (regardless of the UX). My traditional arguments that complexity is at the heart of all evil do seem to go hard against this idea that I can code an app one time and deploy it everywhere. Clearly, this is not how it works out in practice, but the savings are definitely somewhere in the middle and detectable.
What does HN think about the complexity argument for using electron?
I actually find that Spotify is super buggy. If I switch devices it doesn't work (I have to select the new device at least five times), when I go underground with my phone it's super slow to realise that I've lost connection, and I usually have to restart the app for it to continue playing music.
For me switching playback device is quick and reliable if the device is a PC or phone. Whenever I try to select a connected Google speaker... it takes like 3-5 tries. I've found it is more reliable to use voice commands to get the speaker to play Spotify then I can use a phone/PC to select the song/playlist/podcast/etc. but it's kind of frustrating it just doesn't work well to begin with.
My major issue with Spotify is that they keep changing the UX on me every week. I hate being part of some terrible a/b testing that I didn't consent too. They already have my money, why do they feel the need to tamper with my experience more? It's extremely infuriating.
I remember something was posted to HN a while ago about exporting your playlists from Spotify. That's my current hurdle to leaving the platform, if I can do that and whichever service allows me to import these playlists I'll be leaving.
Big tech UIs are never made to satisfy the user. They are made to balance you between annoyance and acceptance. Just enough that you wont leave, but still getting frustrated by the aweful mechanics. In a way its also a good thing. Gives room to create a better variant
I think the point is that "all modern software" has all kinds of delays and buffering before playing, in contrast to this site where the audio just plays instantly and reliably.
They don't though? I just clicked between two tracks a few times. Each time I switch there is a very clear delay between the click and the playback starting. You can even visually tell there's a delay because the row only becomes highlighted when playback of that track starts.
When you click, you download packages between 30kb and 300kb (roughly speaking); the player is surely already in memory - that is your latency. For systems that run immediately on machines with a fraction of power.
This comment makes zero sense considering that mod/XM type tracker files are mere kilobytes in size as opposed to a streamed OGG or MP3 file which is megabytes.
The browser can play any sound so why not MIDI files. To be clear, the default implementation here is that this uses a soft synth (FluidSynth) compiled to wasm to render MIDI to waveform data - this is not how browsers classically played MIDI through the OS sequencer. It does also support sending out MIDI data to external devices though.
You're right! Why is that? Shouldn't regardless of the app (Chrome vs GarageBand) the sound be the same? I mean the underlaying player should be the same right?
MIDI files only contain a description of (simplifying somewhat) the rhythm and base pitch of notes, and which instruments they should be played on, so the realisation can vary drastically depending on the particular system and configuration (e.g. soundfont choice) it's played back with.
That's the nature of MIDI files. They don't encode audio, they encode a set of instruments with a list of notes. It's up to whatever's playing them to provide what those instruments actually sound like.
Here's an example of the same MIDI file being played back on several different devices: https://youtu.be/eiMP-PlL6VM?t=954 It's clearly the same song on all of them, but it sounds slightly different.
Modern browsers do not support MIDI playback on their own, so chiptune.app is presumably doing it on its own with its own (likely intentionally retro) sound font providing the instruments.
Additionally even if macOS had its own system-level MIDI synthesis (not sure if it does), GarageBand would actually probably still be different since it's main purpose isn't MIDI playback -- it's to be a DAW.
MIDI does not have a sound. It's just instrument data. The classic "MIDI sound" that you recognize is the Roland GM soundkit shipped with Windows (an early version of Roland's Virtual Sound Canvas product).
This website uses a different instrument set. You can actually select which one it uses in the Settings panel, but by default it uses Kenneth Rundt's GMGSx.sf2 (which does sound quite a bit Roland-y to me), as shipped by SynthFont.
I don't know what instrument collection GarageBand uses.
Btw I just want to say that I tried CANYON.MID and it sounds worse in GarageBand. I guess like using retina display to see old JPEG files, the imperfections now visible.
What is playing this back? When using the inspector, I see it actually downloads the .mid file. I didn't grant Chrome access to my MIDI devices (not that I'd have any connected) and it was still playing the audio.
Is it playing it back with some internal samples and a playback feature, relaying it to the OS, or is this a Javascript player?
--
Oh wait, I just turned on the Visualizer, which makes me think that this is all done in Javascript, including the audio rendering?
I'd guess the hard work is done by the WebAssembly blob. There are open libraries written in C and C++ for the rendering of just about any audio format into a sample buffer. For General MIDI playback you could use e.g. the TiMidity++ or FluidSynth libraries, which use instrument data from SoundFont files.
The Roland SC-55/SCC-1 one would probably be an authentic sounding choice for GM/GS game soundtracks after the early 90s, since a lot of the soundtracks were actually composed with it. Doom (and its sequel), Duke Nukem 3D, Descent, the Warcraft games (though the WC2 composer(s?) used an SC-88 as well) just off the top of my head.
Or Masquerade 55, if you want higher fidelity but with SC-55 replacement in mind.
Space Quest III predates General MIDI altogether. I assume that the original soundtrack was composed for the Roland MT-32 and that the ones you are listening to have been remade into GM by fans, or maybe it was added in a later version. It would be nice if this player contained an MT-32 emulator since so many Sierra (and other) game soundtracks were composed for it specifically. Such a thing already exists: https://github.com/munt/munt
GMGSx Plus is basically a Roland SC-55 sound-alike, except with the Piano patch swapped with a nicer one from GeneralUser GS. Good tradeoff of size and sound quality.
There's a huge variance in Soundfont quality, and the craft put in by Soundfont authors to program all the modulators properly makes a huge difference. GeneralUser is one of the best. https://schristiancollins.com/generaluser.php
For people trying to play this in Safari: reload the page if you get no sound. I’ve some experience with safari on mobile and wasm. Audio is unfortunately quite wonky.
"The term is commonly used to refer to tracker format music using extremely basic and small samples that an old computer or console could produce (this is the original meaning of the term)"
emphasis on that an old computer or console could produce (this is the original meaning of the term)
chiptunes on Amiga (mod, xm) where reproducing samples of the sounds created with HW synthesizers (CHIPs), like, for example, the C64 SID, one of the most popular ever.
For example the intro of "Cannon Fodder"[1] on the Amiga is not considered a chiptune, because it used samples from real instruments and a human singer
For some original true chiptune, see the amazing work of the amazing Rob Hubbard[2]
The 8bit electric guitar of Skate or die still gives me goosebumps almost 40 years later[3]
"emphasis on that an old computer or console could produce (this is the original meaning of the term)"
Yes, old computers and consoles with sampling capabilities. Chiptune means to "emulate" older sound chips with sampling hardware.
In the nineties SID music was just SIDs.
"For example the intro of "Cannon Fodder"[1] on the Amiga is not considered a chiptune, because it used samples from real instruments and a human singer"
Agreed.
"For some original true chiptune, see the amazing work of the amazing Rob Hubbard[2]"
Rob's work is amazing, but I really don't think he'd refer them as chiptunes.
In the early nineties, as a demo (intro) coder you wanted a chiptune when you had space constraints. 40 kB total for code / gfx / music, which was a pretty common size limit for Amiga intros that time, so you had maybe 4-15 kB for the chiptune.
> For some original true chiptune, see the amazing work of the amazing Rob Hubbard
His Commando tune is pure gold, I still love it after about 40 years since the 1st listen. A real song that I plan to make a rock cover one day, hopefully before I die (did I say I'm quite lazy?:)
Others already did metal covers, sometimes with good results [0]. My idea is to keep it funky like the original and use mostly real instruments.
You may be correct about wording, it was a life time ago and I only spoke about this in Swedish. I think one of the trackers I used called itself a chip composor, there's a nice archive of these things things (some of them quite recent) here https://dhs.nu/files.php?t=chipeditor
"Chiptunes" means that some microprocessor was used as a sound synthesizer. In the initial years, you coded the tune. Then a standardization happened, as music code could be generalized in "sound patterns" definition and organization: hence, e.g., Chris Huelsbeck's Soundmonitor (1986). That is one of the first public "trackers". The name comes from the Ultimate Soundtracker on the Amiga (1987) - but the Paula was more typically used as a sampler, not as a synth. Speaking of "chiptunes" implies a style - that may or may not be the output of a tracker (it depends on how it is used).
I'm old enough to remember playing games with chiptunes, but young enough to not have known what a tracker was. This YouTube video (from the amazing Ahoy channel) is an incredible, in-depth overview of trackers, their sound and history:
185 comments
[ 149 ms ] story [ 172 ms ] threadMartian Lovesong
Point of Departure
Paranoid Android
Reminds me of a Chiptune player I made a wile ago (with Chiptune.js), but with only like 20 predefined Cracktros. If anyone is interested: kleemans.ch/static/chiptune
I don't know much about the MIDI format, but there was one song [1] that I used to love listening to on Windows 9x. I guess the file took advantage of some 9x quirk, because the orchestration is completely busted in modern Windows and macOS. I'm so happy because this site plays it just the way I remember it!
[1]: https://chiptune.app/?play=vgmusic.com%20MIDI%2Fconsole%2Fse...
Here's a video I found of one of my favorite games sounding completely different from how I remember it: https://www.youtube.com/watch?v=inn7IE6-wgY
MIDI files: a table of notes and variations for playing default samples for instruments.
Chip synthesis programs: code that generates sequences of sounds, requiring some specific synth engine.
The former two have a radically different (lack of) complexity compared to the latter...
yes, but also the VIC timers and the PLA. So basically you need all of the c64 chips emulated, at least in part :)
I wrote a simple SID player for fun and I feel like it's 20% shy of being a full c64 emulator, all it needs is video output and keyboard/joystick input.
I wrote a simple program that transformed basic (60hz, no PCM-style hacks) SID programs to like sequence of byte instructions for the SID chip so that I could replay without emulating and the file sizes are massive compared to the original!
Here is an awesome single file SID player written in C,
https://github.com/mlund/csid/blob/master/csid.c
I wrote mine in C too and it's basically a 1k line switch statement for every 6510 instruction :) I went the extra mile and made it cycle-accurate though.
libsidplayfp is probably the best emulator out there. It actually emulates voltage levels at one stage. The wiki has a bunch of info on SID reverse engineered from die shots https://github.com/libsidplayfp/SID_schematics/wiki
The term chip music was coined on amigas and newer computers to differentiate it from regular sample based music.
Of course these are indeed modules, arranged by someone else than the original composer, and not SID tunes per se.
I hate electron and the CTOs that use it almost as much as I had “cross-platform” mobile apps.
That sort of garbage is coding to the lowest common denominator of device rather than optimizing the app for the capabilities of the hardware.
The reason why some engineers need to be managed by Product and Project is that they don’t think hard about all the constraints, such as the cost of developing multiple native apps vs. the benefit that would provide.
This is often due to a failure of empathy: many engineers envision the common user being like them, when really the common user doesn’t know, notice, or care about whatever this “Electron” thing is.
I’ve seen, time and time again, developers having loud opinions about how choosing X over Y is because people are dumb, or cheap, or inexperienced. Those are all possible, but not nearly as common as they think. They’re easy explanations. But I rarely see developers do the engineering part where they quantify the issue and make a case for picking X over Y.
If developers hate Electron so much, the answer is to develop the skill set for making an informed argument that isn’t limited to just things like RAM and latency and file size. These often aren’t compelling business reasons. They’ll either learn more about why Electron gets picked, or they’ll have a solid case to make for why not to pick it.
I'm on a four-person team building a React Native app. RN is awful, I'll admit, but it would be impossible to work at the pace we do if we were maintaining fully parallel Android and iOS codebases.
Besides, it's the hardware's job to optimize for the capabilities of the SDK.
> Besides, it's the hardware's job to optimize for the capabilities of the SDK.
You can't possibly blame the hardware manufacturers for how poorly React Native runs. Even if the CPU engineers wanted to target React specifically and make it run better somehow (and you seem to think they should), where would they begin? React sits on top of 35 layers of software abstraction and runs in 2-3 virtual machines, how could they target RN?
Assuming they could add magical instructions that benefit React somehow, who's going to patch the 34 lower layers for React to benefit from it? The manufacturers? The React team? You?
[0] My main beef with React Native is the total lack of useful stack traces. Also, when running on a device, when you tap Debug before manually setting your dev machine's IP, the app is bricked and you have to delete and reinstall it.
This is why you need to become king. In many places, it is the only way to truly deal with this nonsense. Top-down.
If you want a big org to defenestrate electron, your #1 mission is to generate a very scary narrative that electron is a 'legacy' technology and that your competition is already 2 steps ahead. You could spin little lies like "I overheard a member of KPMG discussing our competition's use of SSR and native local apps to deliver leading-edge UX while at lunch last week".
The super shitty thing about electron is that it does, arguably, reduce the overall complexity of delivering an end solution (regardless of the UX). My traditional arguments that complexity is at the heart of all evil do seem to go hard against this idea that I can code an app one time and deploy it everywhere. Clearly, this is not how it works out in practice, but the savings are definitely somewhere in the middle and detectable.
What does HN think about the complexity argument for using electron?
I remember something was posted to HN a while ago about exporting your playlists from Spotify. That's my current hurdle to leaving the platform, if I can do that and whichever service allows me to import these playlists I'll be leaving.
When you click, you download packages between 30kb and 300kb (roughly speaking); the player is surely already in memory - that is your latency. For systems that run immediately on machines with a fraction of power.
Additional feature idea (for remixing)
- Play several tracks at once
- Keyboard shortcut to toggle each voice channel (soundboard)
Here's an example of the same MIDI file being played back on several different devices: https://youtu.be/eiMP-PlL6VM?t=954 It's clearly the same song on all of them, but it sounds slightly different.
Modern browsers do not support MIDI playback on their own, so chiptune.app is presumably doing it on its own with its own (likely intentionally retro) sound font providing the instruments.
Additionally even if macOS had its own system-level MIDI synthesis (not sure if it does), GarageBand would actually probably still be different since it's main purpose isn't MIDI playback -- it's to be a DAW.
This website uses a different instrument set. You can actually select which one it uses in the Settings panel, but by default it uses Kenneth Rundt's GMGSx.sf2 (which does sound quite a bit Roland-y to me), as shipped by SynthFont.
I don't know what instrument collection GarageBand uses.
Also, it’s so unexpected to see this text-style UI scroll smoothly or update the progress bar smoothly.
Is it playing it back with some internal samples and a playback feature, relaying it to the OS, or is this a Javascript player?
--
Oh wait, I just turned on the Visualizer, which makes me think that this is all done in Javascript, including the audio rendering?
This is wild. Anyone who’s more into this space than I am have any editorial comments on the various SoundFont options?
…listening to Space Quest III…
Or Masquerade 55, if you want higher fidelity but with SC-55 replacement in mind.
Space Quest III predates General MIDI altogether. I assume that the original soundtrack was composed for the Roland MT-32 and that the ones you are listening to have been remade into GM by fans, or maybe it was added in a later version. It would be nice if this player contained an MT-32 emulator since so many Sierra (and other) game soundtracks were composed for it specifically. Such a thing already exists: https://github.com/munt/munt
There's a huge variance in Soundfont quality, and the craft put in by Soundfont authors to program all the modulators properly makes a huge difference. GeneralUser is one of the best. https://schristiancollins.com/generaluser.php
Can't tell you how glad I am to hear that at least one other person has used Chip Player JS this way.
Eg. Sonic 3 ice cap zone https://chiptune.app/?play=Sega%20Genesis%2FSonic%20the%20He...
In the 1990s chiptunes meant *tracker (Protracker, etc.) tunes with short loops used as instruments.
https://en.wikipedia.org/wiki/Chiptune
"The term is commonly used to refer to tracker format music using extremely basic and small samples that an old computer or console could produce (this is the original meaning of the term)"
chiptunes on Amiga (mod, xm) where reproducing samples of the sounds created with HW synthesizers (CHIPs), like, for example, the C64 SID, one of the most popular ever.
For example the intro of "Cannon Fodder"[1] on the Amiga is not considered a chiptune, because it used samples from real instruments and a human singer
For some original true chiptune, see the amazing work of the amazing Rob Hubbard[2]
The 8bit electric guitar of Skate or die still gives me goosebumps almost 40 years later[3]
[1] https://www.youtube.com/watch?v=PiYuq6Ac3a0
[2] https://en.wikipedia.org/wiki/Rob_Hubbard
[3] https://www.youtube.com/watch?v=vqRXxPl6bXA
Yes, old computers and consoles with sampling capabilities. Chiptune means to "emulate" older sound chips with sampling hardware.
In the nineties SID music was just SIDs.
"For example the intro of "Cannon Fodder"[1] on the Amiga is not considered a chiptune, because it used samples from real instruments and a human singer"
Agreed.
"For some original true chiptune, see the amazing work of the amazing Rob Hubbard[2]"
Rob's work is amazing, but I really don't think he'd refer them as chiptunes.
In the early nineties, as a demo (intro) coder you wanted a chiptune when you had space constraints. 40 kB total for code / gfx / music, which was a pretty common size limit for Amiga intros that time, so you had maybe 4-15 kB for the chiptune.
How do I know? I was there.
Not disagreeing with what you wrote, I was replying to "Absolutely no one referred to SID, YM etc. tunes as chiptunes in the *nineties*"
They absolutely did in the 90s.
I was organizing chiptunes nights in my city in Italy in the late 90s early 2000s and we were calling it either 8bit music, chip music or chiptunes.
I did not invent the format, I discovered it in Berlin at the times.
The guys in Berlin told me that they imported it from Tokyo ¯\_(ツ)_/¯
His Commando tune is pure gold, I still love it after about 40 years since the 1st listen. A real song that I plan to make a rock cover one day, hopefully before I die (did I say I'm quite lazy?:) Others already did metal covers, sometimes with good results [0]. My idea is to keep it funky like the original and use mostly real instruments.
0: https://www.youtube.com/watch?v=f2rws8l4Kiw
https://youtu.be/roBkg-iPrbw