Just one thought, I've done some work with wxWidgets in the past and it seemed very similar to MFC. I wonder if that wouldn't be faster to use when porting?
I'm aware of wxWidget's likeness to MFC, and it might be possible. To be perfectly honest, I'm not that familiar with MFC or wxWidgets. I tried to learn MFC when I started programming in C++ (2005), and found it confusing and difficult. For multiple reasons, like non-portability and MFC only being available in "acquired" versions of Visual Studio, I haven't tried to learn it again.
I can actually do (some) stuff with wxWidgets. wxWidgets would've definitely been the most lightweight solution, as opposed to lugging around the Qt library for .tar.gz releases (13MB on x64 Linux, 6MB compressed). I just know Qt better than wxWidgets, so that's why I use it.
Actually, I feel it's faster to just eye the UI and work that from scratch, because there's still the Win32 API to worry about.
On another note,
I hate to impose things, but I do have a request: Can you grant this verson of the FamiTracker core to be licensed under the LGPL?
I'm not a fan of the GPL's "viral" nature when it comes to libraries. One of the ideas of this fork is to allow people to use FamiTracker's player in their own projects without becoming a hindrance to folks who prefer copyfree licenses like MIT/BSD.
This program's licensed under the GNU GPL version 2; it's not as restrictive as GPL version 3 & it's about as liberal as the current LGPL, as far as I understand the wording of it.
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
So first off, I'll explain why I think using the LGPL (or lesser) for this purpose, whether it be v2 or v3, is so important for developers.
The fundamental feature of LGPL that separates it from GPL is that you can use the library in non-free software without releasing the source for it. The LGPL is also less ambiguous with its terms for using it in non-(L)GPL software.
Let me emphasize that I am pushing for LGPL not because the GPL restricts use by non-GPL software. One of the most common assumptions about the GPL is that everything that touches it, including unrelated code, must become GPL'd. This isn't always necessarily true.
Non-derivative portions in a project that contains GPL code can still retain their original license. The work as a whole, if distributed, is under the terms of the GPL. Individual portions of the source code can still be separately licensed.
So if you were to put a copy of zlib in a GPL source tree, it stays under the zlib license because it's not derivative work. As soon as you add GPL code to it, then it becomes GPL'd.
However, if your code is dependent or based on a GPL library, then that work must also follow the terms of the GPL.
GPL v2 wrote:
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Not everybody knows about these rules. At worst, people who don't like the GPL are reluctant in using any GPL libraries for fear of the GPL affecting everything it touches. I see the LGPL as taking away all ambiguity concerning library/module use.
So as it currently stands, one could use the FamiTracker player in their project without their code having to be GPL'd, but only if the code doesn't strictly depend on it. Parts that interface with the player through some wrapper layer are not affected, but parts that explicitly talk to it are affected.
Of course, the GPL is a huge grey area and this will almost certainly be disputed. But that's the point. It's not clear to everybody what the exact terms of using a GPL library are.
tl;dr: LGPL is better than GPL because the terms for using it in libraries is clearer, even though the GPL can sometimes be used in non-GPL'd software.
Pls let me know if you're still working on this. I'd been planning to port FamiTracker to Qt for quite some time to integrate it in some fashion with NESICIDE. Let me know if I can help. I'm familiar with MFC and Qt. I mentioned starting the port recently on #nesdev and was led here. Thanks!
Sorry I haven't been online/updating. I want to put in more features at a time before I put up more previews. The next preview should have JACK audio (currently done) and the 2A03 instrument editor. That and I'm juggling between my other (non-NES-related) project.
Once this is on GitHub/Gitorious, feel free to fork, branch or otherwise use the project. You can actually mess with the source now, but it's very volatile at the moment. In other words, it'll change a LOT. I'll be glad to accept help once the API is in more stable condition.
I might have to strategize making the GUI more pluggable if that's the direction you want to go for. You could just use the .ftm reader/compiler and a simple player rather than attempting to put in the entire tracker, as that'd be the simpler approach. Using the Qt GUI should be doable, though.
One of the current design goals is to make the code simple to use in emulators and audio players. If there are any more applications where you think this could be useful, please leave a post!
The earliest version of Qt that can compile FT is 4.7.1, but that's only because of the placeholderText property in mainwindow.ui. If you take that one thing out, earlier versions like 4.6.x can be used.
I do really like the idea of a handheld FamiTracker. I've never programmed for a mobile device (to my pity), but it'd be so bloody cool to see FamiTracker on these devices.
Of course, it's more sensible to rewrite the GUI for a platform that calls for it. I don't know how well the current GUI would scale on a dinky 320x240 screen, but it's always possible to write a more specialized GUI with only a little bit of work in SDL/Qt.
The code base purposely separates the core code from the GUI code. By studying the Qt version and console-play-ui, you can figure it out.
I have almost zero knowledge of MFC, and it somehow didn't impede my progress. I mean, I didn't really look at the MFC code that much when writing the Qt GUI. The only time I will ever look at it is to know how an instrument or sequence is modified, or something similar. The actual layout stuff really doesn't matter because it all gets rewritten anyway.
Also, please refrain from doing too much with the "core" source code, as the sound sink engine is undergoing major refactoring. Provided you don't touch the core/ directory, If you decide to start experimenting with GUIs right now, there'll only be a few errors when the next preview comes out.
Nice... I've used and looked at mobile versions of a few trackers like Milkytracker, Nitrotracker and Sunvox. Probably the best way to do it is to have multiple tabs and all that. I'll probably model it to look more like Milky, which works quite well. If possible, I could design a more handheld-friendly interface similar to LSDJ.
QT on these devices do not (yet) properly support joypad input, but it might not be a problem if it's not in pure QT... I'll have to look into it. I'll have to set up a QT environment first... should be a piece of cake.
Edit: I've been working on a UI. I just need to find a way to squish it down a little more vertically, and add a small overlay keyboard.
_______________________
Everything moves real slow when it's 40 below.
So just a heads up, I should be putting up preview 3 some time later today or tomorrow. New milestones include:
JACK audio, save support, 2A03/VRC6 instrument editor, legacy sequence fix (my error due to incomplete .ftm reader).
There was considerable pain reworking the sound system (though I didn't touch the internal APU stuff much), but now it's more friendly to callback-based audio APIs such as JACK. There's no fancy channel-mixing stuff yet, but it's planned.
EDIT: It's taking a little longer than expected. I figured I really wanted to do some thread fixes and add channel muting before preview 3 is out. In other words, it should be suitable for making songs.
NukeThePotato, this is awesome! Thanks so much for the Linux build. Looking forward to the next release.
Preview 2 complies fine on 32-bit Ubuntu (11.10).
I had two quick notes about the README. In Ubuntu the package is libboost-thread-dev (you have libboost_thread-dev). Also, for me anyway, I had to call cmake like this:
Eek! It appears I'm procrastinating and not replying in a swift timely manner.
TechEmporium wrote:
Perhaps you should create a website for this project; you already have at least 2 people interested in helping you program this, so why not?
I've considered it. What I'd like to do is find a free project hosting service that provides a blog/wiki and download bandwidth. So Google Code or something will probably act as the temporary hub of this project.
I'm not really up to paying for hosting though, namely because I'm still a (college) student who doesn't make any real money. For the meanwhile, there won't be a "real" website.
hatsize7 wrote:
I had two quick notes about the README. In Ubuntu the package is libboost-thread-dev (you have libboost_thread-dev). Also, for me anyway, I had to call cmake like this:
With the extra "../" at the end of the line to get the right famitracker folder.
The most likely culprit is you put the "famitracker-bin" folder in "famitracker". Put it outside of "famitracker" and it should work.
You're right about the libboost-thread-dev thing. I won't update the README in preview 2, but I will change this in the next one.
--
I said I'd have preview 3 out a few days ago. Well, let's just say that threads are a bitch. The issues are mostly resolved now. (disclaimer: it's my fault; none of the threading issues come from the original source code)
Anyway, I will be releasing preview 3 later today. So stay tuned.
EDIT (6/23): Oh, for the love of christ. I put in note auditioning (previewing), and it really screwed the thread stuff up. This is embarassing. Today, tomorrow, the day after, maybe. Soon-ish.
I've considered it. What I'd like to do is find a free project hosting service that provides a blog/wiki and download bandwidth. So Google Code or something will probably act as the temporary hub of this project.
I'm not really up to paying for hosting though, namely because I'm still a (college) student who doesn't make any real money. For the meanwhile, there won't be a "real" website.
github? Public repositories are free. And you get a wiki. Plus you are already using git as a revision control system.
) 
