chipmusic.org is an online community in respect and relation to chip music, art and its parallels.
You are not logged in. Please login or register.
Documented source of the 'Monty on the run' driver:
http://www.1xn.org/text/C64/rob_hubbards_music.txt
While later players have taken more of a table-based approach to instruments, the basics of most drivers can still be linked back to these '80s ones. Hubbard's driver was also hacked by other musicians but it has such a distinctive sound you can usually tell. 
Fairly complete collection as a demo, with some inaccuracies
The source-code is very interesting, but those pages and pages of .byt look like a really horrible way to compose music (if that's how it was done)!
Yeah Hubbard did it all in assembler afaik and a few of the other legends too. It's not actually that bad (if you set a defs list for the hex it at least looks readable), but can you imagine the incredible patience doing 12 minute songs like Kentilla or Delta that way?
I read that one of those old great c64 musicians (completely forgotten who) actually composed their songs in a code-monitor (assuming most sane people would compose their songs at a piano/guitar/whatever and transcribe it in later)! 
Can't imagine many people doing that now.
Having done a bit of assembler, I can believe people would code music this way. You have to remember that even legends like Hubbard were computer geeks first and musicians second. So it totally makes sense to me that they'd hard code their tunes like this.
Having done a bit of assembler (does this make my opinion more valid or something?), I'm not saying I dont believe they did, just that it doesn't seem like the easiest way. 
I think Rob mentioned in an intervew he'd have the driver running and then tweak parameters on the fly to improve the song as it played. It would be kinda the same as having an editor framework on screen, you're just changing hex bytes in a monitor. I guess once you get comfortable doing it that way then writing an editor takes time away from working, plus it's only a benefit if other people are going to use it.
Thinking about it there weren't really any 'serious' music editors in '84-'85 where you could a) get the music out in a useable form and b) have data small enough to fit in a game. I can only think of Master Composer from that time, which did basic instruments on a stave layout. (if you hear a song cover from the early '80s, chances are it's done in this) Going forward a bit Electrosound appeared in '85, followed by SoundMonitor, RockMonitor and then the flood of editors like Future Composer.
Indeed, jeroen tel demonstrated to me how he composed music in assembler, which seemed like the most annoying way to write a tune.
very interesting thread, please keep the information flowing guys!
... You have to remember that even legends like Hubbard were computer geeks first and musicians second...
while it's true for most of the old legends, Hubbard is in fact a musician, he had classical training 
I dunno, if the assembler you are using is decent then why not? And yes, I know he was a musician, but he was also a real computer geek. After all, there were no pre-made tools, there was no reason to write any when you made your own (which is what the driver is.) I still very actively use old computers, and despite the consensus that assembler is "seemed like the most annoying way to write a tune," I would disagree. If I had sound drivers all made up then it wouldn't really be much different from using a tracker, and possibly more powerful. This is operating on the assumption that one knows assembler well enough to be doing this kind of thing. In that case making music in assembler wouldn't be too bad.
Reading that code was like entering the Matrix o_O
Thanks Mat, it was very interesting. I wonder if I will ever sit down to learn C64 asm coding...
Last edited by akira^8GB (May 23, 2010 9:14 pm)
Reading that code was like entering the Matrix o_O
Thanks Mat, it was very interesting. I wonder if I will ever sit down to learn C64 asm coding...
I lost the plot after about intro lesson 3 or 4. It's something I've always meant to come back to. Although am slowly learning ASM for another console at the moment and it's starting to become clear. :-)
Rob's routines were doubly impressive for their raster time - which was very very low. Still would be challenging to beat today
Composing a tune in an assembler should be the entry exam to calling yourself a "chiptune" composer.
When I wrote my (rather ropey) C64 drivers, I studied Rob's code in a disassembler for a long time, figuring out how he did it. Then I pretty much copied what he'd done, like most other music programmers back then. Later on I made myself a little instrument editor which let me tweak sound parameters and dump the numbers out to include in the assembly file.
I did all my NES music in an assembler in the same way.
cTrix - I think the most impressive C64 music routine in terms of features and efficiency is Geir Tjelta's "Macroplayer". Don't know if he ever released it but he sent me one of Jeroen Tel's old tunes that he'd converted to use the Macroplayer and it was using about 9 scan lines or something mental like that.
Great thread Mat
@neil: Tjelta's player is indeed very impressive! But Frantic coded another player precisely in response to Geir's Macroplayer and it has the same sort of feats but uses even fewer rasterlines. Looking forward to the scandalous headlines when he releases it
About Hubbard's player -- what would be the most different approach to the Hubbard-way (but still aimed for demo/game use)? I know 4mat is looking into these things a bit. If Hubbard still haunts a lot of chipmusic software, what is it that he doesn't haunt so to say?
I'll have to have a look at the Frantic one then Anders (if it's available?) - sounds interesting.
Not sure about a completely different approach but my original NES drivers (and then expanded on even further with Nijuu) broke the "one-track-per-hardware-voice" by having virtual tracks. My NES drivers (and Nijuu) use a "drum track" - in essence it's like a simple SFX track, the sounds defined by little "wavetables" and a priority system. Means that the drums can momentarily steal one or more hardware voices.
I guess to take that idea to it's limit, you'd have an arbitrary (and platform agnostic to some extent) number of tracks that were not explicitly tied to any one voice and then you could have polyphonic instruments etc.
I thought about doing this on the NES while I was coding Nijuu but I shelved the idea, for a while at least
Last edited by neilbaldwin (Jun 1, 2010 7:05 am)
:]