So, I was thinking of starting to make a mod for FamiTracker trying to make it let you completely customize what channels you use. Another thing would be to fix some quirks in the audio chips and making some other small modifications to how they sound in general.

However, the problem here is that I don't know what tools I need for modding. I know the source code is there, but what can I use to compile it? Most of my programming experience is in assembly. All programs that I've used to program C styled programming languages had their own compilers and the code would only work for that program alone.

I might need help in the modding process itself since I don't know how FamiTracker is programmed, but we'll go over that later if necessary.

Visual C++ 2010 compiler, as well as Visual Studio Community 2013 / 2015; enable the Microsoft Foundation Class library during installation. Some C++11 features are available for VC++2010, including the smart pointers (in std::tr1) which you can readily use to remove the BoostLibrary.

About channel order: the FTM format already stores members of chan_id_t into the HEADER block while saving, but does not read them:

You might want to use a separate data block to store the channel order since these values might indeed be read in a future version of FamiTracker (0.5.0 beta 5 does not), unless compatibility is no longer a concern. Be prepared also to be able to export the correct binary music data to deal with the missing / reordered channels, since you cannot easily patch the driver header files without recompiling the ASM sound drivers yourself. It might be slightly easier only if hiding unused channels is the only action allowed.

HertzDevil wrote:You might want to use a separate data block to store the channel order since these values might indeed be read in a future version of FamiTracker (0.5.0 beta 5 does not), unless compatibility is no longer a concern

I probably not going to make updates for the later versions of FamiTracker.

HertzDevil wrote:Be prepared also to be able to export the correct binary music data to deal with the missing / reordered channels, since you cannot easily patch the driver header files without recompiling the ASM sound drivers yourself. It might be slightly easier only if hiding unused channels is the only action allowed.

For the tracks to be able to be played properly inside FamiTracker is enough. If I ever need a wav file I can just record the playback from Stereo Mix with Audacity or something. NSF files are not needed either and they probably won't be compatible with any NSF player anyway. If I'm ever going to need any kind of "music data", I'm probably going to convert the music data "by hand" from the tracker itself.

A while back I had an idea of making emulator system for a "imaginery" (or non-existent) console that I can the use to program games with assembly language and possibly release them without having to worry about copyright issues. The reason I want to use emulated system is because I like old games and I have always liked how they sound and how they react to bugs and glitches. Most new games just give you error message and close, but old games usually get completely messed up or produce sometimes very amusing results. The fate of this idea depends entirely on how well I learn programming in C styled languages.

Modding FamiTracker would allow me to sequence the music for games for that "system" (although not the only use since you can mix the channels how you want). This is also the reason I want to fix some of the audio quirks to make it sound better. Other changes I want to make is possibility to use multiple DMC channels and make them not affect noise and triangle volume and have a volume setting for triangle. Another change would be that the noise channel would have a lot wider range of "pitches".

Roflo wrote:So why not using an other DAW instead of messing with famitracker' fucked up code?

^.

Also, your ability of using C-like programming languages has almost nothing to do with understanding the structure and organization of FamiTracker's source code; object-oriented design does not end at the syntax and semantics of a programming language. I can assure that you will be refactoring the code most of the time rather than implementing said features.

What I said about the code itself still applies, and if multiple instances of the same sound chip are allowed, you should also be prepared to remove chan_it_d::CHANNELS from as many places as you can, but exactly where to remove it depends on your specification. I hope you could find a way to remove the 2A03 chip in one way or another.