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
Since I wasn't able to create a poll in the original thread, I'll create it here instead. Vote away!
I don't think the results will mean much at the end of the day, it is still jsr's decision whether to release the feature to the public or not; but at least it'll make it clear how many are for it and how many are against it. Maybe if there's an overwhelming percentage of aye's it'll happen, who knows!
i voted for yes/in famitracker. it probably is not a priority tho, and i don't support further work on it (i don't think trying to get it to be "intelligent" by automating instrument creation, speed, frame length etc. is worth it at all. way too much work. that is a project in of itself.) the 60hz way is fine, which is basically how openspc converts SPC to IT.
anyway assuming it works the same way for all NSFs from commercially released games, i guess it's done already?
I think I'll agree with Dave on this one. The current 60Hz way of doing this is all people should really need to satisfy their needs. Advancing it any further seems like a waste of time to me.
Although this does beg the question as to how E# macros will be implemented. As far as I know, adjusting the clock speed of FamiTracker doesn't change the tempo to go past 900bpm. How will these macros be handled in the editor, would it just approximate the value at that given point in time?
Giving this a second thought has really made me consider if it is actually possible to get accurate results with this method...
Although for 60Hz games I am all for this! Mega Man 1-6, it's time to finally understand how you work!
This would be a really fantastic tool for ripping the instruments from games (as Sam suggested) and I'm guessing that, if he ever decides to do this, it would be easiest for jsr to release it as an external application rather than working on building it into a new version of FT.
It going to be as useful as VGM import in Mod2PSG2. I.e. not much at all. Usual pattern of 64 rows at speed 6 after export and import turns into two patterns, one of 256 and other of 128 rows, at speed 1, and all the instruments are 1 frame long, and all the effects or song structure are gone.
Import of NSFs created by FT itself, i.e. decompiler, would be more useful (like, you accidentaly lost your FTMs but still have an exported NSF). I guess it is possible to recreate at least some proper song structure from a NSF compiled by FT. Such a feature could be a separate tool, as it rarely needed anyway.
I voted yes/in Famitracker, but come to think of it, having it as an external application would allow other people to work on that project while jsr concentrates his efforts on the main one, which is of course FT.
Yes in FamiTracker as well. I mean; just like Mex mentioned; if it can be done manually, why not consolidate it all into FamiTracker & just make the entire job easier? Otherwise, an external application would be just fine (& yes; even though I don't use the latest version, I still acknowledge the fact that it's best to have this feature in the next release of FamiTracker).
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
I would vote no as an add-on, because it would add a whole NSF player/logger to the source code of FT. But... I don't really care. If jsr wants to add it that's his prerogative.
All I want is a nice stable NES tracker, and he's already accomplished that really well. I haven't even personally run into any bugs that aren't extremely easy to work around.
If he doesn't make an NSF->FT logging tool, it's possible for anybody with some technical knowledge to do. All you need is an open source NSF player and the FTM file format (also open source). If NSFPlug didn't already exist, I'd maybe consider writing it myself if jsr doesn't want to.
) 