I have worked on SnevenTracker, a fork of FamiTracker emulating the SN76489 chip, to the point where it may be considered something slightly more than a proof-of-concept build. Originally just a demonstration of emulating a different sound chip with FamiTracker's interface, it has been repurposed as a drawing board for the successor to 0CC-FamiTracker, the other larger fork that I am known for. But let's be honest here: being open-source, FamiTracker should not have taken more than a decade to spawn a mod that does not use the Famicom/NES. It should not have taken more than a decade for most of these issues to be rectified. This statement is where I talk about the current status of my development, as well as my opinion about the future of FamiTracker modding.
(Before I continue, I should note that there is no such thing as an unofficial build unless it bears the same name as the product it is based on. 0CC-FamiTracker is the official branch of 0CC-FamiTracker. jsr's FamiTracker is the official branch of FamiTracker, and Slimeball/Sylveon's N163 mod unofficial, for instance. I shall refer to jsr's creation as the "vanilla branch" from now on.)
There have been a lot of discussions of supporting other sound chips on top of FamiTracker's tracker interface. Calls for a universal chiptune tracker with the expressiveness of FamiTracker are frequently heard from chiptune musicians of all systems, including myself. This is concrete proof that FamiTracker's design is highly functional and usable; but, functionality and usability do not stop at the GUI. The target audience of FamiTracker comprises also potential developers who want to implement additional features, however compatible they are with the vanilla branch. The ease of use must extend to users of the source code itself, especially for a category of music where composing and programming are equally important. This is a fundamental difference between free software and freeware/donationware.
As you may know, vanilla FamiTracker has not seen a new stable release for almost 2 years. Doing so often takes more than a year, but the version 0.5.0 beta builds alone take one and a half. It has also been rumored that the creator himself is no longer interested in his project; much more than ever do people believe that the vanilla branch is as good as discontinued. My other fork, 0CC-FamiTracker, is also gradually receiving fewer commits; when the next Winter Chip or Famicompo Pico starts, the remaining changes will be published as 0.3.14.5, and after that I will return my focus to SnevenTracker, for reasons to be given below. I cannot say for sure when 0CC-FT 0.3.15.0 or 0.4.0.0 will be out, but the refactoring in SnevenTracker will definitely be ported to 0CC-FT in preparation for its eventual successor.
The FUTURE.md file in the SnevenTracker repository lists various plans to make its source code, hence that of FamiTracker and 0CC-FamiTracker, more reusable and amenable to changes, towards the ultimate goal of a generic chiptune tracker. Regardless of whether FamiTracker remains a Famicom/NES-only tracker, these are plans that increase productivity in the long run. Some of these are for implementing features which sound trivial to add, but are actually extremely tedious in practice due to lack of locality and organization in the code infrastructure; for example, adding a new pattern effect type requires modification in about 8 distinct places for 0CC-FamiTracker, which has so far done no refactoring for them, inheriting much of the structure from the vanilla branch. It has been so for more than a decade, and the work on SnevenTracker is supposed to put an end to that.
A tracker supporting multiple sound chips should behave the same whether any single chip is enabled or all of them are used simultaneously. FamiTracker was not originally planned to include extra systems, so despite having added 6 expansion chips, it still gives 2A03-related code the first-class status of being a default sound chip. Therefore, the earliest commits of SnevenTracker all relate to removing the expansion chips. However, as it stands right now, the 2A03 chip is not yet removed from the source code, in the sense that only one default sound chip is replaced with another default option; until the SN76489 is isolated from the core interface, the desired granularity is not achieved, thus any work related to implementing extra sound chips ought not to be done at this stage. Eventually it should be possible to speak of instantiating zero or two SN76489 chips, by virtue of this multi-chip functionality.
SnevenTracker, however, is not primarily a place for developing whatever makes the source code more modular; only the modifications related to sound chip support would be carried out, as these are also the only ones necessitating the removal of the expansion chips. Classes that can be refactored or rewritten independently of other classes in 0CC-FamiTracker will naturally happen there, as are further extensions in other aspects, such as the pattern editor or more plugins instead of just a seldom used custom exporter interface. This helps determine more concrete goals to achieve with SnevenTracker, and provides an upper bound on its feature list as a proof-of-concept fork that will eventually be merged.
There are many reasons I chose to fork the current vanilla stable release instead of building upon 0CC-FamiTracker. The most important one is rewriting as much code as possible while only one sound chip remains in the SnevenTracker source; almost every change requires recompiling more than half of the classes, so what matters is the overall simplicity of the code. When there is only one sound chip, there is also only one set of classes to maintain and debug, instead of seven. Large portions of the code can then be redone as if expansion chips never existed (circa vanilla 0.2.7), without fearing that anything can be broken. Although many classes have been decoupled in 0CC-FT, these are not exactly what I look for when modularizing sound chip support, and there is simply too much to remove for saving little time, since it continues to use FamiTracker's existing sound chip interfaces.
It would be more beneficial to the community to start from a totally new sound chip instead of, say, 2A03 or 5B/AY. The SN76489 chip offers a good candidate; its implementation is very simple, it has a lot of variants and configurations, it is often used alongside with other sound chips, it can borrow FamiTracker's existing sequence instrument facilities, etc. A chip like that can bring about most of the necessary alterations to the code interface, and at the same time give people something new to compose with. Besides, despite improbable, these changes might be incorporated by the vanilla branch if and when it resurrects itself, as SnevenTracker's code resembles it more than 0CC-FT's does.
The vanilla branch has become dormant along with its support forums. With now more 0CC-FT-user-and-non-FT-users than I expected, and chiptune competitions suggesting widespread use of 0CC-FamiTracker, any progress that I make in SnevenTracker right now will finally end up in one of the de facto standard NES chiptune tools available. I believe that I am the only remaining person who actively maintains a FamiTracker derivative; I also believe that I have the paramount responsibility in this community to make FamiTracker's source code more usable. This responsibility outweighs the demand for any immediate feature in SnevenTracker or 0CC-FamiTracker because, without these changes, the tediousness of adding the bigger ones will only scale with time. But, more importantly:
I do not want to be the last person developing on top of FamiTracker.
I say this as a chiptuner who loves both the coding and musical parts of my endeavour. I have seen many people who have the knowledge for C++ and the ideas for new features, yet do not want to bother with the source code to realize those ideas; the reason might be a lack of documentation in the source files, or simply the fact that FamiTracker does not utilize object-oriented programming principles to their best. Others simply tell people to "tell HertzDevil to add that to 0CC-FamiTracker", not recognizing their duties and rights in a modern world of open-source chiptune software. This defeats the whole point of making the source of FamiTracker and its mods publicly available. If I care about FamiTracker's source more than most other users, and also have the ability to render this source more accessible, then I shall be willing to serve this community before we have to wait for another year or decade.
SnevenTracker will be considered feature-complete once it is able to emulate the YM2612 chip, after which only non-crucial updates will be applied. Is there an estimated release date for that? Only time will tell. On one hand we waited for 11 years to witness the creation of SnevenTracker, on the other hand most of the preliminary works on it were committed within a single week. Given the number of public and private projects I am responsible for, I cannot even be sure if SnevenTracker will be completed before I switch focus to something else, but this is unlikely since that essentially means stopping my involvement in 0CC-FamiTracker. I too want to be able to track for multiple systems in one powerful tracker.
How do we raise interest in the development of FamiTracker? The best way is probably to allow writing plugins in a scripting language, which are easy to write and may hide many boilerplate details behind mod developers; C++ plugins are less popular but yield greater control to the programmers. Either way, the source code itself must reach a high degree of modularity before we can discuss such possibilities; people should first be comfortable to write mods like ipi's unofficial build and ÜberTracker, whether there will be a plugin system. Plugins are therefore a long-term consideration for 0CC-FamiTracker with medium priority, as they most certainly should not be done at this stage.
If one day the generic chiptune tracker becomes a reality, will people really continue writing mods or extensions for FamiTracker derivatives? That is another thing beyond my control. I doubt that jsr anticipated anyone to make a full-fledged fork out of FamiTracker when it was first debuted in 2005; and here I am, building upon the works of the Arpeggio Scheme Mod since September 2014. There are at least six mods of FamiTracker that were made by other people, to varying degrees of completeness and compatibility. We cannot be sure that a new mod will be spawned within any period of time, but we can always believe so.
I will keep developing SnevenTracker with the focus of supporting multiple sound chips in a modular way, so that this functionality can be delivered to 0CC-FamiTracker eventually. I do not want to be the last person developing on top of FamiTracker; progress made on SnevenTracker should foster users of FamiTracker's source code itself by making it more extensible.