And that's beside the fact that NSFs made using FamiTracker's compiler are best suited for import because each effect/note/setting translates to a particular set of assembler opcodes & operands. This means the whole concept of importing FamiTracker-made NSFs into the tracker is easier than rainwarrior's description because each NSFs assembler code follows a certain pattern.
If FamiTracker-made NSF were optimized, then you'd have to do like rainwarrior said.
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
And that's beside the fact that JSR's method only works for NSFs made using FamiTracker's compiler because each effect/note/setting translates to a particular set of assembler opcodes & operands.
Really? What about the Silver Surfer rip in this post? Surely that wasn't made in FamiTracker. :p
My bad; I've corrected my post above (I didn't really clarify & explain myself well).
But yeah; it's much easier to import FamiTracker-made NSFs because they all follow the same compilation method, whereas other NSFs wouldn't be as easy to import.
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
Of course, one of the inherent dangers of such a feature (were it to be made available) is that one could potentially take NSF rips of actual soundtracks, run them through the NSF import feature and claim those were 100% accurate covers that they made
Uhh, well why is this an art whose integrity needs to be preserved anyway? It's great practice of transcription and understanding music, and it has a rich value for that purpose, but there is no art in the musical part of the end product; it's only use is maybe to show others what they might have found had they transcribed it themselves. (Or to make it easy to revise/remix.)
Which... is exactly what a tool would do! I use various tools to assist in transcription already, low speed playback, etc. what's wrong with automating more of that process? If you really want the musical practice you can still do it by hand any time you like.
Of course, one of the inherent dangers of such a feature (were it to be made available) is that one could potentially take NSF rips of actual soundtracks, run them through the NSF import feature and claim those were 100% accurate covers that they made
Uhh, well why is this an art whose integrity needs to be preserved anyway? It's great practice of transcription and understanding music, and it has a rich value for that purpose, but there is no art in the musical part of the end product; it's only use is maybe to show others what they might have found had they transcribed it themselves. (Or to make it easy to revise/remix.)
That's my point: you and I both know that very well, that it should only be a tool for educational and assistance purposes. But there's still going to be a few herp derps out there who will take advantage of this to pass rips of original tunes from classic video games as their own, and that is the "risk" that I'm trying to expose here.
Uhhh, people already do that plenty. It's already dead easy to steal someone else's music; this would only make it a very minute bit easier. It's not like you're going to stop plagiarism by holding back an FTM transcription tool. :P
I think it's more of a lazy man's way of doing things (instead of doing things the more ethical nicetas_c way).
How is this a matter of ethics? It just highlights the pointlessness of 100% superaccurate covers of same system songs.
edit:
TechEmporium wrote:
But yeah; it's much easier to import FamiTracker-made NSFs because they all follow the same compilation method, whereas other NSFs wouldn't be as easy to import.
it doesn't matter what engine it was made with. every song will look like that, at 60 fps, just as "inefficient" as the silver surfer one, even if it ran at a slower speed. you could import from the most clunky horrible engine ever made or the most complex one, and you'd get the same result because this is just a log of what the registers are doing. this is, essentially, how .vgm format works.
Tim Follin is the Chuck Norris of chiptunes. Your swing version is, in fact, not better :P
Though incredibly hilarious.
More on topic. I see absolutely no reason the desire for 100% accurate covers to be done by hand should stop Famitracker making it easier to do so.
The point of 100% isn't about gloating the work one has done. It's about the learning experience. I think this tool would aid that.
I'd like to go on record by saying I'm not against the idea per se. I'd definitely be chuffed to see it implemented, actually. I was just voicing my tiny concern about it that's all. :p
ha yeah this is exactly how i thought it would be implemented if at all, very much like how nsf to midi works. there's really no other feasible way to do it. nonetheless, very cool! and has a lot of potential.
i lost my FTM for one of my songs in a hard drive crash. i'd love to get it back with this. since it was made in famitracker does that mean everything including original speed, number of frames, instruments etc. would be preserved? i had considered that impossible.
) 
.png){kind=avatar}
