TFMX for ScummVM

Alot happened since my last post, this probably means I should update more often. Unfortunatly Im rather the type that adds just-another-thing(tm) before bragging about it.

When I did the last post I was very motivated to improve the quality of the playback, which proved to get more and more difficult. The quality of the music posted on the 6th June was already good and what was left was implementing a few more effects Monkey Island is using and finding bugs which affected playback. Implementing new effects is rather straightforward, but some new effects suddenly caused heavy regressions aswell. I was already past the point beeing able to rely on the available opensource TFMX-Players (tfmxplay) so this meant timeconsuming reversing of the “Monkey Island” executeable. In the end the most trivial bug kept me occupied a whole day. Around the 10th June I had a Player which supports all effects Monkey Island is using.

Today I managed to enable sound support for Monkey Island, looking at the scumm-engine I initially felt totally lost. But with the help of one of the ScummVM devs (_sev) I found the hooks already waiting for my code. Its still hackish and maybe even causes problems sometimes during the game, but you can try it out for yourself: (Editor’s notice: This file was hosted on the now defunct hosting provider hotfile[.]com. It is not available anymore.)

Now what up next?

I found out a couple of  things while adding MI-support, for one than not only the music but also the sfx are done with TFMX. Its not documented anywhere how these are invoked and I got to reverse and add this to the player aswell. And of course improve the integration into ScummVM.

While cleaning up and verifying my code I was able to fix a couple (stupid late-night) mistakes and this caused an immense improvement. Before You needed much imagination to hear out correct melodies, but now everythings sounding mighty fine. Ironically this kept me up late night once more for potentially making more stupid bugs.

I shouldve kept some before/after recording, I just have some recordings of the current state: (Editor’s notice: There was a link to the now defunct hosting provider hotfile[.]com. Unfortunately, the file is not available anymore.)

I cant believe its almost 2 weeks since I started working on this, the long weekend sure helped with that.

My project went well so far, no big issues yet except beeing behind my own schedule. But luckily theres enough time to compensate for that and I worked a bit “sideways” by running a bit through the disassembled MI Executeable which will surely be handy.

I succeded in creating a simple replayer, it steps through the TFMX-Modules and even outputs … noise, its not anything close to what it should sound like yet. I spent the last day (rather night) trying to fix playback but no joy so far. I modify the player to just run a single channel on a part of a module so I can locate the problem easier.

I chosen to implement the bigger part first by beeing able to run through whole Modules, in retrospect I could`ve focused on playing back simple segments of it first and then improve upon that – might have been faster alltogether. I`m always smarter afterwards and sometime it might require running my head against a wall first.

On the other hand, now that I have the routines ready, the player should gradually get into shape as I fix the parts, which is very motivating to see. =)

I expect to be able to play back parts of modules the next few days, then clean up everything to have a solid base for further improvements.

So far I more or less have a simple player which steps through patterns and tracks. Still not much of a joy since I cant really verify everything is working as intended, the reason for this is for one the complexity of the format. Unlike eg. Protracker, there are 8 independend channels for patterns(which can loop, jump or have subroutines each), so there is no easy way to visualise whats going on the whole player.

For another reason, the player (both the OS tfmxplay and the disassembled MI-Executeable) dont give much hints or have many sane restrictions and checks about parameters. It would be quite easy to craft TFMX-Modules that result in both these players ending up in an infinite loop (in more possible ways than you could count). Probably it is even hard not to do so when you just naively try to create a module.

Im now trying to produce some sound, which means I have to implement enough of the macros and effects together with tracking their state so I can atleast playback some samples. I hope I will be there in ~2 days, I gone from re-coding everything myself to copying stuff from tfmxplay and adopting it to my needs. This should speed up my short-time progress at the cost of having to cleaning it up or reimplementing later. I really want to literally hear a lifesign of my work.

Since the 23rd was the starting day of the GSoC, I will give this blog some live and will try to update it atleast once a week.

This time I will outline my task a bit, I will start explaining a bit about TFMX.

Soundgeneration on computers can be summed up roughly in 2 categories:

• Noteplayers: You give them a frequency and they produce the right tone until a specified time runs out or you tell them to. Most early Computers and Consoles (C64, Nes, etc ) were limited to this kind of music. The familiar PC-Beeper is another example.

• Sampleplayers: Instead of simple tones, you can playback any kind of sample.

Since you can easily “abuse” a Sampleplayer by feeding it sampled tones, any Sampleplayer is also a Noteplayer – it just potentially needs alot more Ram as you might need multiple samples for different tones, instead of simply specifying a frequency. An example for a Sampleplayer is Wav/Mp3 Playback (doesnt matters if the sample is compressed or not).

TFMX is one of these so-called Trackers (not a 3rd category as it also uses samples in the end), it consist of a Timetable in which certain actions can occur, be it notes / samples to play, or effects enabled. Perhaps best way to understand whats happening is to simply look at some of those trackers working 😉 (you see the patterns flowing for 4 channels flowing through): There are a few on youtube.

To summarize the Format, heres an attempt at an overview:
On top of everything is the trackstep, its a series of commands that are processed in order, like stopping playback, repeat a pattern n times, play this pattern.
Next are the patterns, those could be compared to note-sheets for musicians, but are more than that. A pattern is most of the time in control of a single channel, and this means that a couple of them are running in parallel (Amiga has 4 Hardwarechannels). To make matters complicated, patterns not only contain simple notes, but can trigger more complex effects and even execute some simple command like branches,loops and subroutines (to other patterns). Those branches and subroutines make it hard to predict which patterns belong to a song and how often each pattern is played (and this is why players often cant reliable seek or even predict the length in such formats)
Lastly macros are some of the effects patterns can start/stop. Most importantly though they are responsible for playing back samples.

So what I`m doing now for is using the existing format-documents, some pieces of source-code and a bit of trial-and-error to get a rudimentary TFMX-Player going.
Its rudimentary in the sense as its not required to sound anything like the real thing (or produce usefull output at all =) ), its purpose is simply to run through the right patterns in the right order. I expect to be occupied with that for the coming week.

Hi there,

The purpose of this blog is to document the progress of my work during this summer, thats as short as it gets.

For a bit of a backstory: Google holds annually a nice program called GSoC (Google Summer of Code), for which I applied and ultimatly ended up as one of the 1000 students chosen.
My task will be to improve ScummVM (Script Creation Utility for Maniac Mansion), particulary by adding support for additional Soundformats including TFMX(The Final Musicsystem eXtended)