Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
I was thinking a while back that it would be cool if there was an import plugin feature to complement the export plugins. Lately I've been thinking about the kind of export workflow you need to make a game, and I was taking a look at Shiru's FamiTone process, and I realized there may be a simple way to satisfy these needs really well.
I propose to remove export plugins, and replace them with the following:
1. Make the text exporter a part of the main program.
2. Create a corresponding text importer.
3. Allow text export via the command line.
Having 1 and 2 would give us a much easier to use interface than trying to build a plugin DLL, and open up import/export/transformation scripting to a much wider audience (no longer limited to just windows C++). For a game workflow, 3 is key to being able to automate your data builds (this would also help with creating export-transform-import scripts as well).
It would also allow me to rewrite the NSF importer as a stand alone NSF-to-TXT tool, which could more gracefully coexist with FamiTracker, rather than being something I have to hack into it.
jsr, I'd be willing to write these changes myself, if you think it would be a good thing to do.
I actually got an account to create a topic about a potential generic export plugin I may write. One that exports the instruments, patterns, frames etc. in separate well documented formats.
That way, whoever wants can just write a command line app to parse those files to take the data needed. I had not even thought of an importer, but the idea is great.
Maybe we don't need to get rid of export plugins entirely, but having a decent text-exporter built in, especially one you can do via command line, would have tremendous utility.
I think removing the exporter would be problematic, because I know at least a few who are using it. But I don't think that will be of any hindrance, and the text exporter is already available and easy to modify if needed. I've started adding support for command line switches, including an option to export files. The only thing needed would be a way to specify the export method to access the text exporter.
If you want to add an importer then that's ok. You can create a branch if you need.
Okay, I might try to implement it in a few weeks. I don't imagine it would be too complicated, probably wouldn't need a branch.
Yeah, I wouldn't get rid of the exporter plugin system if people are using it. I mostly just meant that if there was a good built-in text exporter, that could satisfy most of people's custom export needs without anybody being tied to having to build a DLL with C++.
So... update: I've actually implemented this. I guess my dream will become reality in the next version of Famitracker. The great hope is that it will make it much easier to build tools to work with Famitracker documents (since every programming language can work with text). Here are some things I will probably do with it:
[ul]
[li]Parse text to make animations based on FTMs.[/li]
[li]Export music into a custom engine format for NES.[/li]
[li]Write export -> process -> re-import scripts to automate tasks that are too specific to be a feature in Famitracker.[/li]
[li]Export two versions of an FTM, and do a text diff to find out what changed.[/li]
[li]Generate text documents from NSFPlay as a replacement for NSFImport. It won't need to be a hacked Famitracker build any more![/li]
[li]Generate text documents based on MIDI files.[/li]
[/ul]
I've attached an example of what the text version of a Famitracker document looks like.
You know; this sort of reminds me of the old ASM source exporter in FamiTracker 0.2.7. This & the fact that both can technically be used to convert between FamiTracker, MCK & ASM if used properly.
As for MIDI to text, I honestly wouldn't recommend it unless MIDI import is working as it should. I haven't tried MIDI import for 0.4.1 yet, though.
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
I meant using it as a means to get MIDI data into Famitracker, since the MIDI import isn't very good.
Really this can be used to import anything. People have been requesting a GBS import for a long while; this would actually make that easier to accomplish.
I wish ppmck was like this instead of programming, GOD IT WOULD BE SO MUCH EASIER!
_______________________
Some other sites I have made shelter on...
[url=http://www.youtube.com/user/KingGlitchofGlitches]Ye Youtube
[url=http://chipmusic.org/glitch_king]Ye Chipmusic
[url=http://battleofthebits.org/barracks/Profile/Glitch_King/]Ye BotB
_______________________
Follow me on [url=https://twitter.com/jrlepage2a03]Twitter.
I record (some) NSFs on hardware. Feel free to [url=http://www.famitracker.com/forum/posts.php?id=3633]request a hardware render.
[quote=jrlepage]Not really.[/quote]WHY MUST EVERYTHING BE SO DIFFICULT!! *flip table*
_______________________
Some other sites I have made shelter on...
[url=http://www.youtube.com/user/KingGlitchofGlitches]Ye Youtube
[url=http://chipmusic.org/glitch_king]Ye Chipmusic
[url=http://battleofthebits.org/barracks/Profile/Glitch_King/]Ye BotB
) 
