nesdev.org

Not too long ago I added a feature to Famitracker which will allow you to write an exporter for your own sound engine that works with Famitracker. I also wrote an example sound driver and an example exporter DLL for that driver. It is based on concepts I learned from the Nerdy Nights sound tutorials (thanks MetalSlime!). I'm hoping some people out there might be able to use the example out of the box in their own games and then maybe improve it for their own use, or write exporters for other sound engines.

I wrote the feature mainly because I didn't need quite as much sophistication as the Famitracker driver had built in, I wanted a lightweight driver that would make sound effects easy to implement as well. And, more importantly, I wanted to still be able to use Famitracker to compose the music.

*edit* There have been lots of edits to this top post, but I wanted to keep it clean and not have too many links to old builds of stuff. The following will be updated as bug fixes and so on are added, until the next release of Famitracker is available.

Here is a new development snapshot, with some new features. The plugin interface is now a pure C function interface, so plugins can be written with non Microsoft compilers. I have included information in README.txt on how to compile an example plugin with g++ under Cygwin as an example. Also, a new function, GetExt, has been added to the interface, as per Shiru's request, so that plugins can suggest what extension is appropriate for its format.

*edit* A development snapshot, containing source, windows XP binaries, and a demo rom
Famitracker Development Snapshot, December 24th, 2010

*edit* A link to just the demo rom if you want to see the example sound engine in action
Example Sound Engine Demo

Here is a link posted by Shiru in General Music and Sound Solution to a plugin he wrote which can export in a parsable text format.
Parsable Text Exporting Plugin

Here is Shiru's thread about his new sound engine, FamiTone, that can be used with this plugin system: FamiTone.

The example is now up here: exporterplugin.zip
It contains all details needed to write a plugin.

Wow, this is great news. I'm definitely going to look into it. This should make recruiting musicians for your project much easier.

Thank you Gradualore and jsr!

In README.txt, Gradualore wrote:To build the example_exporter_plugin, you'll need an environment
that can build Famitracker (DirectX 9 I think, and the Platform
SDK).

Windows SDK: 1.5 GB download. Or does Microsoft make it available on DVD-ROM?

So here's my humble feature request: an exporter that creates a text file containing all of the info in the FTM in a stable, fairly easy to parse format. Then people could pipe this text file into a filter written in Perl, Python, JScript, GNU C++, or whatever else might already be installed on the developer's machine.

Not only that, but MFC doesn't come with Visual Studio express. Maybe some day Jsr or another contributor to the project might adapt Famitracker for use with Qt...we'll see.

Windows SDK: 1.5 GB download. Or does Microsoft make it available on DVD-ROM?

Go to a friend's/relative's house, an internet cafe, a public library, or anywhere else where they might have a high-speed internet connection. Bring a USB stick with you that you can copy all the files to. Or a laptop/netbook if you've got one and the place provides WiFi access.
Problem solved

The download is only part of the problem. Installing something this big on your PC will require quite a bit of HD space and who knows what other resources. Not worth for this 1 time thing if you ask me. Why do things have to be so bloated and so invasive nowadays?

Gradualore wrote:Not only that, but MFC doesn't come with Visual Studio express. Maybe some day Jsr or another contributor to the project might adapt Famitracker for use with Qt...we'll see.

NESICIDE (written in Qt) needs a tracker!

/me goes to download the FT source...

I had considered, while developing this system, finding a way to isolate exporter developers from MFC. I may yet add this as an improvement for a future release. Then all you would need is the ability to develop win32 dlls. We'll see.

Gradualore wrote:I had considered, while developing this system, finding a way to isolate exporter developers from MFC.

A text serialization of all info in the .ftm isolates exporter developers from not only MFC but also Win32 itself. NESICIDE, a Qt app, could call the exporter in FT and then parse the text that it generates. In theory, this would work even on a Linux machine that can run FT in Wine.

That's a really good idea, tepples. My hope was that people would get creative with this plugin system so perhaps someday someone can write such a plugin. Maybe I will, if I find time!

The easiest way would probably be to isolate the interface classes, then only a compiler that can compile DLL files is needed (no MFC or SDKs).

Another thing I just tried was to manually declare all things needed by the internal header files and that appeared to work as well, this could be included as an optional header file.

If there is a Binary avalible, Can you please post it here? I really could not build it, and the current SDKs are not worth it because of the internet I have!

I wouldn't mind sending a binary of the example plugin dll to anybody interested. Just send me a pm.

*edit* see the top post for dev snapshots, demo rom, and additional plugins. (there had been a link here to an old build of the example plugin)

This is good news to hear. This way you can use FT for making music and export in the format you want.

In the future, maybe all export from FT should be external (nsf, FT binary, raw text data etc). You would just be adding one new dll in the folder for some new functionality.

As for the dependencies, I would try to remove them since it doesn't make sense unless you need them inside the dll itself, which shouldn't be the case since you parse data only.

If possible, I would try to see how to make it a COM interface. I'm sure some people must be looking at me and thinking "what the hell are you thinking!? COM?! barf!" (etc, etc). There is one reason for this: if you make the plugin COM based you can make the DLL in any language that support COM. This mean: win32, vb6, .net etc. New light programming should be made in .net anyway and with the included framework, there is no reason to not do so.