In FT, Shift+Enter plays from the current row and upon reaching the pattern's last row, continues on to the next pattern. Alt+Enter plays from the pattern's first row and loops that pattern only. I suppose that's how it should be in the Linux build as well, if faithfulness to the original version is a concern of course.
I believe FT lets you change these shortcuts though.
To be fair though, that stuff's really hard to find out. When I look in the menus, there's no mention of it at all.
I don't think Shift+Enter and Alt+Enter do anything by default. It would make more sense to assign them to the various playback methods, though. Reaching to press F7 is a bit unintuitive.
I really wish I knew about F7 a long time ago. It would have made writing slow songs with long patterns much less annoying.
Yeah, I agree about reaching for F7. In regular FT, F5 plays from the start of the module, and although there's no alternative for that (by default at least), it's slightly unnatural doing so. Still, it's not something I do often enough that I'm annoyed by it.
Hitting F7 is practically second-nature for me at this point. I think it would be a better idea to keep them in for consistency with the Win32 FT, even if that means duplicate shortcuts.
_______________________
Everything moves real slow when it's 40 below.
For some reason I'm unable to compile the third preview.
Quote:
jp@jp-VirtualBox:~/Desktop/famitracker-bin$ cmake -DCMAKE_BUILD_TYPE=Release -DINSTALL_PORTABLE:BOOL=TRUE -DCMAKE_INSTALL_PREFIX=../famitracker-install ../famitracker
CMake Error at /usr/share/cmake-2.8/Modules/FindBoost.cmake:1123 (message):
Unable to find the requested Boost libraries.
Unable to find the Boost header files. Please set BOOST_ROOT to the root
directory containing Boost or BOOST_INCLUDEDIR to the directory containing
Boost's headers.
Call Stack (most recent call first):
src/core/CMakeLists.txt:25 (find_package)
CMake Error at /usr/share/cmake-2.8/Modules/FindBoost.cmake:1123 (message):
Unable to find the requested Boost libraries.
Unable to find the Boost header files. Please set BOOST_ROOT to the root
directory containing Boost or BOOST_INCLUDEDIR to the directory containing
Boost's headers.
Call Stack (most recent call first):
src/famitracker-core/CMakeLists.txt:76 (find_package)
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:91 (MESSAGE):
Could NOT find ALSA (missing: ALSA_LIBRARY ALSA_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:252 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-2.8/Modules/FindALSA.cmake:39 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
src/sound/CMakeLists.txt:3 (find_package)
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
Boost_INCLUDE_DIR (ADVANCED)
used as include directory in directory /home/jp/Desktop/famitracker/src/famitracker-core
-- Configuring incomplete, errors occurred!
I'm a complete Linux noob, I never use it, ever. I have a virtual machine that I set up a year ago for testing purposes, but that's it. If you could help me try out FT for Linux that'd be great.
What distro are you using? It looks like you need to install the development headers for Boost and ALSA. If you're on Ubuntu/Debian/something based on those, try:
As icesoldier pointed out, you need the development packages in order to compile. In Ubuntu 12.04, you can run "sudo apt-get install libboost-thread-dev libqt4-dev libasound2-dev". You can optionally add libjack-dev if you use JACK.
I don't say how to obtain them in the README because it varies in different distros/package managers. If you can't get it to compile, you can always use the binary if you have a 64 bit VM.
Don't expect this to perform very well in a virtual machine, though. I got FamiTracker running successfully in a Fedora 17 VM, but the latency was really high (about 600ms). Okay for playback, but not okay for editing.
It is still being worked on, just at a slower rate. I actually just started school in September, and that unfortunately means I have less time to work on the project.
So, what has been done in that time? For one, I decided I wanted to get FamiTracker running on Windows. ...Okay, it already does. So I decided I wanted to get this version running on Windows. It's a work in progress, and DirectSound doesn't work yet.
So, one might ask, why in the world would I do that if FamiTracker is already on Windows?
I want to ensure projects like these are truly portable. If there are more systems to target, each new system should in theory be easier to target as the APIs are forced to simplify. A simpler API should also carry the benefit of less bugs.
The other reason is that additional features may hypothetically exist in this version. I'm not that interested in doing anything to fragment the ftm format or NSF drivers, but perhaps there would be other features in UI usability.
This version of FamiTracker also has a new name! It doesn't carry any deep, meta-symbolic meaning, but it's nevertheless a way to identify this version from the original. FamiTracker CX.
The "CX" doesn't mean anything in particular. This is coincidentally a lot like rainwarrior's suggestion "FamiTracker LX". That name would've been fine too; I independently came up with CX when juggling with names and it stuck for me. If people think "LX" or something else is better, it can still be changed.
So sorry again for the slow updates. I'll try to get a release with a >80% complete GUI up sometime this month.
I'll also aim to get a Google Code project started fairly soon.
If people are going to get your binaries running with newer *nix distros these days they need to be able to play nice with the latest version of GLIBC/libc6. Compiling my own was fine, but for those who are just dabbling they may get scared off.
Thanks for the tip, B00daW. I got it to build with GCC 4.5.4, but it was giving me runtime errors (don't remember of what sort). Was coming back to poke those issues after updating to 4.6.3 because of Hopper, but now it works well.
For those wanting to try it, if you don't plan on installing it to your live system, I'm going to recommend making sure to set an install prefix that your user owns and also toggle making a portable build. Makes life a little nicer.
Potato: Will you be pushing this to github/bitbucket/etc over Christmas break?
So I finally have time off from school to work on this again. I'm just doing some (massive) code clean-ups in the GUI portion, and should have this on GitHub and Google Code in the following week.
I didn't do as much as I wanted with the GUI at this point (still no undo/redo), but I did manage to optimize rendering with the Pattern viewer (>2x faster than before). Also added were "recent files" and a settings file.
I try to be careful with dependencies in the binary builds that were posted. For the console player, the only unbundled libraries that need to be on the user's computer are libc6, libpthread, libm, libdl, and other "standard" libraries. libstdc++6 is bundled because another C++ ABI on the system can potentially break the program. I'm still unsure on how and when system libraries "conflict" (for example, if a C++ program relies on a system library that uses a different build of libstdc++6).
I'm reasonably sure that any modern distro with libc6/X11/glib will be able to run the binary builds provided. If they don't work, be sure to holler (and do some debugging if you're brave. ).
Improved GUI, including recent files and module properties
ncurses
One of the more interesting features is the ncurses player. It's meant to emulate the look of older tracker programs, and to address the Linux niche of weird terminal shit.
Really, the only reason I made this was because it's a cool throwback. It's a love letter of sorts.
A little technical background on why opening some .ftm files would crash previous versions
Essentially, if your .ftm file was too new or used an unsupported expansion chip (like VRC7, Namco or S5B), the program would explode. Not for any good reason, but it did.
Ever since v0.4.1 came out in September, opening new .ftm files in preview 3 would crash the program. This is because in prior releases, if an invalid file was opened (whether it be too old or corrupt), there would be nothing to catch any assertion errors. In the original source, there were MFC message box calls in the original document reader, so I was still sorting out proper error handling at the time. In this release, it becomes clear if a file is too new, is corrupt, has an unsupported feature, etc.
VRC7 (and Namco and S5B)
The reason VRC7 wasn't included earlier was because of possible legal issues pertaining to the license of emu2413.c, the chip's synthesizer. As it turns out, the license was merely missing from the distributed version. After snooping around, the Medafen project's website says the file is under (or was upgraded to) the zlib license. I'm putting faith that they know what they're talking about, so I think this assessment is reasonable.
S5B suffers a similar problem where I don't know the legal status of 2149.c. It's written by the same author, so it's likely safe to use. But I don't know yet.
There was actually never any legal problem using the Namco chipset. It's just awkwardly wedged into FamiTracker, and I've been putting it off.
I've compiled Famitracker-CX on my Raspberry Pi. Running the QT UI with a full X desktop isn't very fun (I haven't tried running it on its own yet); the RPi Model B with "moderate overclocking" doesn't have enough resources to run even one channel at a slow speed, but the terminal player works very well.
_______________________
Everything moves real slow when it's 40 below.
).
