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
It makes writing tools for manipulating/reading .ftm files very easy and also works great when using version control software like git to track changes!
Why I'm bringing this? It's because I think that just this two points are an important improvement over the binary .ftm. Have you considered switching the main ftm format with a text version in a data serialization language like YAML, JSON (Or even XML)?
Besides what I began the post with, it would also provide greater portability between architectures and future-proofing. Having it as the main project file format it also avoids some of the inconsistencies that may arise from having it only as a import/export feature that may easily fall out of sync with a version update (and, you have to update the text exporter/importer with every change to ftm, so there is more work involved)
Yes, of course that a text markup file will occupy more space and will need more resources to be parsed... but its not 1990 anymore. We are talking about a difference of kilobytes (and people should be using a filesystem with block level compression so it won't even affect you that much.)
As I said, I "don't need it to convert it to XML". I'm talking about using it as a default project file format, like when Microsoft implemented .docx for .doc files.
Why would I need that? It's not about needing but just offering an idea for what I see could be a great improvement for a very popular tracker for the reasons aforementioned (Portability between different byte architectures/ Future-proofing / easiness for parsing / works nice with version control software like Git/Mercurial/Etc; Did you even read? :P)
I think that this, of on the off chance it gets added, should most certainly be an option. Some people (like me) would honestly rather stick to the small size. I've got one 0.75 TB HDD and one 0.25 HDD, and with an entire terabyte, I've got 30 GB left. That add's up more quickly than you'd think, I'm always downloading FTMs. Now, one conflict that could arise, is if someone has a low-capacity hard-drive (like on an actually aforementioned 1990 HDD) and wants to download someones song, but they put it in your suggested version. Then what?
Having two filetypes is just a mess, really, in an application such as this. And it's not a very good programming practice to say "It's not 1990 anymore" and let it be as space-consuming and unoptimized as possible. It's just not. And I'm not sure about you, but I don't really go in and read my modules, anyway.
Some other places I've tried to conquer:
[url=http://chipmusic.org/ch3dd4r]Le Chipmusic
[url=http://battleofthebits.org/barracks/Profile/CH3DD4R/]Le BattleOfTheBits
I've actually considered replacing the current format for ftm files with a better one, perhaps XML based or something similar as the current format is not really good (it's not easy to make changes and has some workarounds for bugs). But so far I've thought of it as too much work as the current format does it's job after all, so there hasn't been any progress on that at all.
The text import/export was actually not created by me, but by rainwarrior. That's the reason it's available as an alternative format.
Btw, even if I'd replaced the format with a text-based one I'd still prefer to compress it before storing it into files, as I don't like the idea of wasting space (even though it's not 1990 anymore). That wouldn't be a problem for other programs, but for version control systems. (Though I wonder exactly how useful it would be to compare the text contents of such module files.)
The "it's not 1990 anymore" was not the best way to express it. What I wanted to say was that when comparing pros and cons, "size" as a disadvantage should not weight today as much as 20 years ago.
Storing it after a pass over zlib for example would be a good decision. (Or maybe only compressing the most compressable parts like the rows, so the format is still easily guessable by a human giving a look at it, until you reach a part like
The only problem is that on all my pc's, I have a pretty low amount of storage left. I'm gonna have to buy another HDD soon anyway, but I would just, if nothing else, like it to be an option.
Some other places I've tried to conquer:
[url=http://chipmusic.org/ch3dd4r]Le Chipmusic
[url=http://battleofthebits.org/barracks/Profile/CH3DD4R/]Le BattleOfTheBits
Ah ok I see, I hope my post answered your question.
Yeah using zlib or something similar was what I had in mind, but in the end I don't think it really matters if it's text-based or another (more suitable) binary based format, as long as it avoids the problems that the current format has (including being easy to read/write for third party software).
I will give this some more thought, but in the meantime I hope the text export/import should solve any needs that might appear for the moment.
Version control programs I've used (svn, perforce) can compress data before sending/receiving it, and the repository server should store its data compressed as well. The uncompressed files only appear on the client's hard drive.
Text data traditionally compresses very well, especially with repetitive text like the stuff produced by this exporter!
So... I don't think it would really make that much of a practical difference of size in version control.
Even downloading from a website, most websites will compress data for transmission behind the scenes. Might not be quite as good as compressing beforehand, but it'll still make a pretty big dent in a repetitive text file (unless the host server doesn't compress; some don't).
It really is mostly a drive space issue, I think. Even there, Windows and other OSes have options to compress folders automatically for a size/speed tradeoff.
zurashu has a neat idea. Text export with a zlib pass on top? I've seen a few programs that use zlib that way, like VGM/VGZ or SNES9X savestates. I like that VGM and VGZ are both available, since when ripping you need to work uncompressed (VGM) and when you're done you don't want to send extra data around (VGZ). Having a different format for sharing/working can be useful that way.
In a way, we have this with TXT/FTM already, we could make it seamless if we just made them both accessible via the regular Open/Save menus (maybe use FTT extension for text, so we have something we can associate). It might be a bit more elegant if it was the same format underneath, just with zlib on one, but we're most of the way there with what we have already.
Thanks for the clarification. The text export solves my needs for the moment (In case you are curious, I'm using famitracker as an editor for a sound driver I'm writing for GB, here is a test with the square channels: http://www.fa-el.com/tmp/hama_test.gb)
I just started the thread because the text export was so useful that would be a shame that as new famitracker versions get released, maintaining in synch the text export/import with the main format can add additional work and support for the text file functions may get behind(And the other advantages I said before)
You do realize that there are people out there like me who can barely afford to maintain the computers they have like me, right? My Win7 laptop w/320GB HDD fills up pretty quickly, and it's crippled with parental controls that make it hard to access compression tools. I do have a WinXP 64bit desktop in my room, but out of an 80GB HDD it has about 17GB left. I can't afford to get a new HDD, and when my laptop battery runs out of cycles or the charger port completely breaks, I need to find an adapter to move my HDD to the desktop PC.
While I do agree with you that the majority of people should not have to worry about storage, there are those who simply can't afford to upgrade to better computers.
I think a better approach to this would be to [b]supercede the binary files[/b] instead of fully replacing them. This is comparable to things like the upgrade of PC monitors to switch from VGA cables to DVI cables. The VGA standard was slowly reduced in manufacturing quantities, while DVI was slowly increased.
Doing this could be started in v0.6.5, and maybe completely discarded at about v0.7.0. That would give a window of time to those less fortunate to gather enough money to upgrade their computers to newer standards, thus allowing everyone to be included in the change.
The screenshot of my HDD usage shows that with just Chrome, Pokemon TCGO, Spotify, FamiTracker (and variants), NSFplay, and drivers, I have used 53GB of available space. Imagine what would happen if I made more YouTube videos, and suddenly got hit with the binary to text only change over. My $329 laptop is an 8 pound paperweight (3.64kg). Other than FamiTracker, it has no practical use due to specs that quickly became outdated for everyday tasks.
Just saying, you can't assume everyone can automatically upgrade to meet a new standard the day it comes out, let alone without financial difficulty.
EDIT: Oops, didn't realize this was such an old thread.
.png)
(1).gif)
