T
his post is going to combine musical notation, music XML, cocoa programming (objective-C for MacOS) and retro game programming (specifically the music) in assembly for C64.
That might qualify this as an extremely niche post, so if you're reading because you're interested in all or some of those things, or if there's some other reason why you'd like to convert sheet music to another format, do let me know if the comments so that I know I'm not entirely alone!
In the last couple of posts in this series I wrote about how I was tinkering around with a little tune for a game I'm writing for C64. Writing out the notation is something I'm very comfortable with.
I eventually arrived at a great and efficient way to store and play the music within my game. This involved using a kind of 'bytecode', combining instructions and data. (A development of code that came with Derek Morris' book). That looks like this:
That looks pretty laborious to write out by hand, particularly looking up the high and low oscillator settings for each note. And I can tell you that it is.
Anyway, for this game that's done now, I have something I'm pretty happy with, other than the voice settings. You can hear that in the last part of this series if you're interested.
But with future composing efforts in mind, it occurred to me that I could seriously turbocharge this process, and pretty much generate the assembly language straight from the sheet music.
First step: parse the music XML (which any music notation software should be able to export to). At first, to save time, I downloaded an open-source class for turning XML into NSDictionary. That appeared to work but after some work I realised that it wasn't handling self-closing tags in the XML, which my musicXML was full of. So that wasn't a time-saver and to be fair the author of the xml -> NSDictionary class has made it clear that it's now out of date and unsupported.
So back to square one and writing code using NSXMLParser. That involves writing a lot of code, but it's useful in some ways - it serialises the data, you can take what you want from it and ignore what you don't want. It was probably no more code than I had to write to extract the data after the XML had been converted to an NSDictionary, and there are no dependencies on 3rd party / open source code.
Here's where we are, in one afternoon (including the abandoned effort and restarting) I can open any musicXML file and see this:
[later update]
... and here we are with the app now converting the notes to high and low frequency values and generating the assembly. Sweet!
Yes I did have to type in the table of values for each note from good old Appendix E (just the decimal value, the high and low values are calculated from that) but now that I've done that, it's the last time I'll have to refer to that table.
It looks like a lot of code, but each of those lines of assembly represents just two bytes in the compiled code, so my entire tune with three voices takes around 1.8k.
That might qualify this as an extremely niche post, so if you're reading because you're interested in all or some of those things, or if there's some other reason why you'd like to convert sheet music to another format, do let me know if the comments so that I know I'm not entirely alone!
In the last couple of posts in this series I wrote about how I was tinkering around with a little tune for a game I'm writing for C64. Writing out the notation is something I'm very comfortable with.
I eventually arrived at a great and efficient way to store and play the music within my game. This involved using a kind of 'bytecode', combining instructions and data. (A development of code that came with Derek Morris' book). That looks like this:
Anyway, for this game that's done now, I have something I'm pretty happy with, other than the voice settings. You can hear that in the last part of this series if you're interested.
But with future composing efforts in mind, it occurred to me that I could seriously turbocharge this process, and pretty much generate the assembly language straight from the sheet music.
So back to square one and writing code using NSXMLParser. That involves writing a lot of code, but it's useful in some ways - it serialises the data, you can take what you want from it and ignore what you don't want. It was probably no more code than I had to write to extract the data after the XML had been converted to an NSDictionary, and there are no dependencies on 3rd party / open source code.
Here's where we are, in one afternoon (including the abandoned effort and restarting) I can open any musicXML file and see this:
... and here we are with the app now converting the notes to high and low frequency values and generating the assembly. Sweet!
It looks like a lot of code, but each of those lines of assembly represents just two bytes in the compiled code, so my entire tune with three voices takes around 1.8k.
Comments
Post a Comment