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.
Quote:
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.
The famitracker plugin system should now, I think, be usable and accessible. You can compile a plugin with g++ under cygwin at least, but any win32 compiler should work fine. The interface consists of pure C functions. There are no MFC dependencies.
See the top of the thread for a snapshot download for anyone interested in playing with the plugin system.
Banshaku wrote:
New light programming should be made in .net anyway and with the included framework, there is no reason to not do so.
Barf!
<Sorry...just couldn't resist!>
At the top of this thread, I've posted a link to a compiled ROM demo of the example sound engine, and the original famitracker song from which the data used in the ROM was exported. Press "A" to hear a sound effect.
Gradualore wrote:
I wouldn't mind sending a binary of the example plugin dll to anybody interested. Just send me a pm.
Actually,
here it is. Just drop it in a folder called "plugins" next to famitracker.exe. Then, the export dialog should list "SoundEngine" as one of the file formats.
I'm having trouble with Famitracker's export functionality.
I've downloaded Famitracker 0.3.6 beta 4 to my Windows XP PC.
I created a directory called "plugins" at the same level as FT.
I've installed both export plugins mentioned in this thread.
I saved your "example_song.ftm" to my desktop.
I fire up FT, and open up your FTM file.
Now I look in all of the menus and I can't find any that read "export".
The "save as" only lets me select "FTM" file types.
What have I done wrong?
Code:
C:\>dir C:\opt\famitracker /s/b
C:\opt\famitracker\FamiTracker.chm
C:\opt\famitracker\FamiTracker.exe
C:\opt\famitracker\Plugins
C:\opt\famitracker\Plugins\SoundEngineExporter.dll
C:\opt\famitracker\Plugins\TextExporter.dll
It is in File>Create NSF (in the Type of file dropdown list).
Shiru wrote:
It is in File>Create NSF (in the Type of file dropdown list).
I must have done something else wrong. Under "type of file", my only options are NSF, NES, BIN, PRG.
EDIT: Procmon shows that FT did indeed open the two DLLs in the plugins directory. Procexp shows that they are loaded into FT's address space.
WTF: My computer hates me. The export options are available now. Damned Heisenbugs.
I apologize for the trouble.
EDIT2: I take it back. The options are missing again. WTF!!!! The export options are only listed when I monitor the process with ProcMon.
My normal user account lacks admin rights (principle of least privilege). I am not sure what is going on at the moment, but I suspect that it is a file permissions issue on my end.
I've figured it out.
Famitracker looks for the "plugins" directory relative to the processes current working directory (which is normally whatever directory contains the FTM file that I double-clicked on from Windows Explorer).
Famitracker should instead use the win32 api "GetModuleFileName (NULL, ....)", then strip the EXE off with "PathRemoveFileSpec", then append "Plugins" with "PathAppend" (or at least, that is how I would do it).
I suppose I'll create an account on FT's forums and post a bug report over there.
EDIT:
http://famitracker.shoodot.net/forum/posts.php?id=1511
*edit* You're quite right. Yes, that should be fixed. Thanks for the bug report. I probably never found this because I always run famitracker first, then open a file.
@clueless, this has been fixed, using your suggestion. Thanks! I'm not sure if this is quite drastic enough to issue yet another development snapshot; but let me know if you'd like one anyway. *edit* Nevermind, here's a second build from today with a fix for the bug clueless found:
Dev snapshot, December 12th 2010, build 2
Gradualore,
Nope, I'm good for now. Thanks for the offer though.
What software license do you plan to attach to your own music player (ca65 src)?
I haven't given much thought to a license. I intended it to be an example so as far as I am concerned it is public domain and you can do whatever you like with it, improve it, etc.
DPCM support has been added to the plugin system. Shiru's FamiTone player looks to be fulfilling what I wanted for the plugin system. There is a development snapshot available at the top of the thread as well as a link to Shiru's FamiTone player thread.
This thing has the same problem it always has for me, the plugin shows up on the menu for Create NSF... but... it won't export anything. Just closes the save dialog and sits there like nothing happened.
Thanks for posting about your problem, without feedback this will not get off the ground. PM coming.
ManicGenius's problem was corrected by installing the Visual Studio 2008 runtime. We believe that this is only a problem in how I compiled the example binary for the plugin.
Jsr has released the new Famitracker v 0.3.6 on the famitracker website. He updated a link to the latest source for the example plugin and driver, however there is not yet a binary available. I will make one available soon and will update this thread accordingly.
According to Jsr there are plans to create a "plugins" section on FT's wiki which would list exporter plugins developed for famitracker. Currently there are two: the example exporter/driver, and Shiru's text exporter/FamiTone.
Hello guys,
I am 80% done with a tool that directly converts Famitracker FTM files into ca65 compatible assembly. The tool is implemented in whatever C dialect that MSDEV Studio 98 (vc6.0, sp6) will compile. It also compiles cleanly with gcc-4.4.4 on my Linux development server. (I do my nesdev on both, and shuffle code back and forth using svn).
I find it tedious and annoying to run a point + click export plugin inside Famitracker, and then run a secondary tool (text2data, from famitone) to convert the TXT into nesasm assembly, and then a perl script to convert from nesasm syntax into ca65. So I'm cutting out the middle-men.
My converter does not handle DPCM (yet), as I don't plan to use DPCM in my current project. I plan to release the source under the GPL (same as Famitracker). I've tried to ask jsr on IRC if he wanted the source to add as a "command line utility" to Famitracker, but he's not been on and/or ignored me.
I had planned on adding support to emit assembly in nesasm syntax too (changed via a command line switch).
However, since I began studying the Famitone source code, I've decided to change the output format a bit, and I plan to modify Famitone accordingly. Famitone indexes its instruments as arrays of structs. The 6502 is not very efficient at this. Much more efficient would be to store the data as a single set of arrays. That is, split arrays of words into two arrays of bytes (lsb, msb, separately). I think that I can make Famitone use less CPU if I handle this correctly. Of course, I will share any changes that I make.
I think that Famitone's pattern table encoding format is pretty slick. Nice job Shiru!
Anyway, The hardest part of the project is just writing the code that will convert the FTM file into an intermediate format in memory. Internally Famitracker uses the word "track" to refer to entire songs (also calls them "tunes"), and to parts of a song, and the columns / rows of the "frame" table. It gets very confusing, imho.
My converter runs as a command-line app on Windows and Linux (and I suspect that it work would fine on a Mac). My design goal is that I would store only the FTM files in revision control. The assembly produces by my converter is just a temp file used during the build process, and removed when I do a "make clean". I'm a big fan on only having one canonical source for source-code in a given project. Storing a FTM and pre-converted ASM file side-by-side for the same original data set seems anti-(something.. . what is the word that I am looking for??) to me.
Does anyone have any interest in my little FTM->ASM project? If not, I'll stop pestering people about it and keep it to myself. It cold a pretty cold reception on IRC from a few people, so I don't know if anyone really wants it other than me.
Well, I guess it can't hurt to share all these different solutions, then people with different preferences can pick among them as to which suits their development style best. I wrote the direct export system for myself, so I shared it in case others like it. If not...it hasn't harmed anybody.
Personally I think you should put this in a separate thread, since it is not part of the plugin system and is an alternative solution.
I'm also puzzled, how is this cutting out the middle man? It seems like you're adding a middle man. Shiru's plugin adds a middle man, but the point of his plugin was to allow yet another alternative for writing new converters for people who did not want to ramp up on the plugin system itself. In the end, the only thing that really cuts out the middle man is to write a new plugin, as in the example I provided. The engine included with the example works well, but does not have enough features to satisfy everyone. What we need is a better engine (perhaps FamiTone) AND a direct export plugin that supports it.
It is actually easy to make a direct export plugin for FamiTone (quick and dirty way: constuct a text file in memory or temp file, then use existing converter code on it). It wasn't done yet just because I'm lazy, and there are things in the converter that could be improved.
clueless wrote:
Does anyone have any interest in my little FTM->ASM project? If not, I'll stop pestering people about it and keep it to myself. It cold a pretty cold reception on IRC from a few people, so I don't know if anyone really wants it other than me.
Referring to me?
While I didn't initially see what use it could be over the plugin system, I think your points about the build system are valid. Anyways, I think couple of hours in IRC is a bad way to measure how interested people are in something. I hope you release the tool for the public once it's ready.
It would be good to have a FTM->ASM direct tool ( I would need NESHLA but that's another history) what I'm really interested in is cpu time reduction, that would be really great.
There are few places in FamiTone code you can change to make it faster, but for most part it will increase player code size (unroll some loops, replace some calls with copies of code). setInstrument routine is indeed is the first candidate for optimization.
I started a new thread
http://nesdev.com/bbs/viewtopic.php?p=73155#73155.
I don't want to hijack Gradualore's thread to discuss a non-canonical Famitracker non-plugin.
Sorry to dredge up this thread, but I'm in need of the custom exporter plugin for testing my Qt port of FamiTracker's ability to use custom exporters. The links in this thread and others seem to be broken. Can someone [Shiru/GradualGames/etc.] PM me a custom plugin for my testing, or fix the links? Thanks!
FamiTone's source, including the text exporter plugin, is at
http://shiru.untergrund.net/code.shtmlEDIT: Maybe missing some header though?
Do you have the document of format of text plugin? It might be useful, that I can make ppMCK to also export such format, and possibly with other programs too to export into such a format, to write whatever music engine you use, that you can then convert text format into music engine format, that you do not have to have all music for the game written with FamiTracker or all with any one other program, in case writen by many people who use different program to write a music, please.
I wrote a text exporter as well as a command line export that is included in the latest version of famitracker. They are completely documented in the .chm included with FamiTracker 0.4.2.
There is no need to try and get that old plugin working, zzo38. This is a more complete text export (exports everything in the FTM, not just the stuff that the plugin author needed), and it's part of the main program, so there isn't anything weird to do to set it up.
Anyhow, cpow, if you need working links for downloads of the old plugins, look here:
http://famitracker.com/downloads.phpI haven't tried them in a while, not sure if they still function with 0.4.2
I don't need the entire program; is it possible to download only the document explaining the format, without downloading and installing the rest of FamiTracker?
Famitracker doesn't require "installation", it's just an executable in a zip (1.3MB). The documentation is in a CHM file in that same zip. Or if you don't like CHM, it's in an HTML file in the source zip (1.1MB).
That's a great news that Famitracker now have built-in comprehensive text export, with sub songs even. Once I'll get to updating my sound tools, I'll replace my old custom exporter toolchain with this, for sure. Thanks, rainwarrior.
rainwarrior wrote:
Famitracker doesn't require "installation", it's just an executable in a zip (1.3MB). The documentation is in a CHM file in that same zip. Or if you don't like CHM, it's in an HTML file in the source zip (1.1MB).
OK, thanks.
rainwarrior wrote:
I wrote a text exporter as well as a command line export that is included in the latest version of famitracker. They are completely documented in the .chm included with FamiTracker 0.4.2.
There is no need to try and get that old plugin working, zzo38. This is a more complete text export (exports everything in the FTM, not just the stuff that the plugin author needed), and it's part of the main program, so there isn't anything weird to do to set it up.
Anyhow, cpow, if you need working links for downloads of the old plugins, look here:
http://famitracker.com/downloads.phpI haven't tried them in a while, not sure if they still function with 0.4.2
I just found this. Thanks for doing this, I plan to write a script for my own sound engine using the text exporter instead of continue to try to maintain the old plugin system. As a result, I won't need to build Famitracker anymore, and so will no longer be dependent on Visual Studio 2008. Thanks again.
That's precisely what I wrote the exporter for!
I have a working converter for the text export to my sound engine now, I think at this point probably the old exporter system (i.e. the one I added, not the original FamiTracker driver) can go away. I don't believe anybody is using it. Probably should be cautious though you never really know who is using what. But I can't imagine anybody is actually using it, it was just a bad design (maybe decent C++ code, but only works on windows, hard to maintain, hard to support new drivers...i.e. just bad). What can I say, I was learning
