FamiTracker Qt

I've been working for the past few weeks on porting MFC FamiTracker to Qt. I'm doing it in a strange way, but it's turning out quite good.

I've created a short video clip since a still-life wouldn't do the progress-to-date on this thing justice.

Basically I've created a MFC HLE for Qt. FamiTracker sits on top of that in darn-near native MFC condition, issuing MFC objects and believing it's in an MFC world [even down to CWinApp, CWinThread, CDocument, CDocTemplate, CView, CWnd, CDC, CFrameWnd, CString, CFile, ... all have been reimplemented in Qt-ways as adapters for the MFC-way]. This will make porting future versions [running right now is 0.41 but I see 0.42 has just recently been released] of MFC FamiTracker to Qt *very* easy.

I must thank hyarion for his help getting the OSX build of this project working. It's not quite there yet, but it's only a few short/simple Windows API replacements away from being there. Then FamiTracker will run native on OSX, Windows, Linux, ...

Enjoy!

EDIT: Moved video to YouTube.

Might this MFC replacement be useful to other developers of MFC apps?

Edit: Why RAR?

Edit 2: Installed an unRAR tool and went off-Market to install VLC which isn't otherwise available in the United States. Is there supposed to be audio?

I had the same thought RE other developers of MFC apps. Yes, I think it'd be useful. I am planning on releasing the MFC HLE as a Qt library when it gets to the point of being releasable. Right now there's only implementations of the object methods used by FamiTracker.

I RARed the video because I was going to attach it to the posting but found that the forum won't let you attach files bigger than 2MB. SO I just uploaded the RARed file to my site instead.

RE sound: No, I haven't yet reimplemented the DirectSound layer into SDL. That's next on my list now that the CWinThread stuff is done and the player is functional. Keyboard input in edit mode is also functional. Also, all of the sound generation stuff including blargg's Blip_Buffer that's used is functional, so I expect sound generation to move along quite quickly, perhaps even by tomorrow.

Then it'll be implementing the instrument dialogs, the configuration dialogs, and a CMenu wrapper for context menus and it'll be darn near done.

FWIW the source is up on GitHub now...

FamiTracker's guts are implemented mainly in a DLL, too, which will make inclusion of FamiTracker in NESICIDE simple. Also...might open up the possibility of creating/using FamiTracker to play songs in whatever application you can think of.

Use YouTube (or Vimeo, or something) else next time. Looks pretty good!

Update: I've reworked the DirectSound interface into SDL and FamiTracker Qt is now playing music! Still a ways to go yet, but it's getting much more exciting now that it's capable of producing sounds! Next I'll be porting the instrument editor dialogs, config dialogs, and exporter backend.

I'll post a video when I'm not firewalled from YouTube.

I love adapting programs this way. Minimal/no changes, and it makes virtually no difference in any important aspect of the executable. Can you add an extra FamiTracker-specific layer that avoids any changes to it? So you have your MFC layer for wrapping this and other MFC programs, then FamiTracker-specific headers that do nasty things like #define foo bar(x) to basically edit the source code without modifying the source files. These headers intercept wherever is possible, possibly by being named say mfc.h (I'm not familiar with MFC header names), doing these nasty things, then including your outer mfc.h wrapper that does all the rest of the wrapping. Basically you use header inclusion as a "come-from" patching mechanism, where perhaps a particular file includes it and you insert a #define for that particular source file. Just some ideas based on my past experience with this fun minimal-modification porting method.

I'm not sure there's much in there that's FamiTracker-specific. Unless you mean the document-view stuff, CFamiTrackerDoc, CFamiTrackerView, CFamiTrackerApp, CMainFrame? Only the base-classes of those [CDocument, CView, CWinApp, CFrameWnd...] are in the MFC HLE.

I will need to split apart the Qt/MFC event handling glue, though. Right now I have stuff like this [example generalized] in the FamiTracker source files:


OnMouseMove is as-is from the FamiTracker source.

For now I'm leaving them in the FamiTracker source, but it'd be nice to have them elsewhere so FamiTracker updates could just be air dropped on top without disturbing the Qt glue or having to do merge-diffs.

I also need to figure out a way to hook in the ON_UPDATE_COMMAND MFC stuff so that the Qt UI elements respond [graying of menu items, etc.].

Still lots to do, but lots of progress so far. That keeps me happy.

This is a nice little project indeed. Hope you can make it work!

Work, it does indeed. I'm not very good at making videos. This is just a bit of playing around. WITH AUDIO!

Now I have no excuses left. This thing will get done! Next up, ported instrument dialogs and configuration dialogs.

hyarion also has been working on the OSX build of this. And I'm sure it'll run nicely in Linux also. It uses SDL for audio.

I'm really excited to try it out on linux! Great work!

Cross post from FamiTracker forum:

Making great progress on instrument editor dialogs.

This is the sequence editor showing the arpeggio graph editor in a dialog test jig. The graph is fully functional -- I can change the levels with the mouse (including the right-mouse line-drag that I just found out looking at the code!).

Instrument dialogs may only be a few more days out.

Any updates on this project? The github link is broken. I see that the last comment here is from March, and it is September. The github link is broken. :/

It is here. The majority of the FamiTracker source is in libs/famitracker. A "window shell" for it is in apps/famitracker [which provides the familiar FamiTracker application interface]. Also it is being integrated as a form into NESICIDE.

Many things have been completed on the project. I put up a Linux-build pre-release a couple of weeks back which failed dramatically for tepples but others have had success with it in Linux. It appears I have some work to do RE SDL stability on slower machines.