I know a forum isn't exactly the place for a blog post, but some would argue a game console isn't the place for FamiTracker.
First off, some replies.re: emulator testingDaggdroppen wrote:Most developers in the 3ds scene use the windows 3ds emulator Citra, for testing

Citra cannot be used to boot a Linux kernel yet, as it is incapable of loading kernel-mode code.
A recommended setup, instead, would be to use qemu-arm to set up an armeabi-v7a/armhf Linux environment similar to, if not identical to, the one on the 3DS.
re: octave selection/scrolling keyboardMiniMacro wrote:Stratelier wrote:It would, however, have to be scrollable by tap-and-drag action
or arrow buttons to go up or down an octave
that would be easier
and in the octave selector's place, a button to toggle instruments display
As far as octave selecting, there will likely be a hotkey mapped to 3DS buttons, an octave indicator on the screen, and an octave up/down button to the left and right of the virtual keyboard on the bottom screen. Scrolling may not be implemented. For one, I don't want to do scrolling, because I may need to render the bottom screen UI in software and spit it out to the framebuffer, perhaps marginally accelerated through DMA, rather than using the Wayland OpenGLES-accelerated top screen, so updating it for live scrolling may be slow. I'm using the bottom screen for static UI elements like instruments and pattern view. For another, tapping and dragging is a bad practice on a membrane/resistive display, even with a stylus. The 3DSFT UI seeks to minimize dragging actions.
re: development hardwareDaggdroppen wrote:Yeah! I'm very happy that you are working on this, sirocyl! You will have a fourth 3DS if you finish your work

I'm not greedy. If anyone needs a homebrew-capable 3DS right now, it's cpow, for testing and development, if he wishes to join in on this.
Also, the cheaper 2DS works equally as well with homebrew, and can be had for much less than the 3DS or New3DS/XL.
re: "warez"/piracy, 3DS homebrew "scene" (plus a rant on homebrew in general)
Daggdroppen wrote:The 3DS scene in general is really sleepy. Its mostly warez. The DS, Wii and PSP homebrew scenes were more than 10x active. So there are not many people who are waiting for Famitracker 3DS. Perhaps some people at chipmusic would like to have Famitracker 3DS. Bet those guys are most interested in LSDj.
I will bring up right now, that this project will not associate with, condone or allow warez or piracy.
If it comes to the point that homebrew development on the 3DS, like on the original XBOX, is made illegal, we will still provide and service the source code under the requirements of the GPL.
The DS, Wii and PSP HB scene was pretty good; the Xbox, PS3 and PS2 also had substantial homebrew development, too, but the Atari 8-bit systems, Sega Genesis/Megadrive, and Sega Dreamcast, have a still-thriving and still active homebrew community, with regular releases!
The reason the 3DS scene is slow, as it stands, is because you either need expensive hardware, or a system with a specific firmware, or to be lucky and never have updated, in order to participate. The PSP was like this for years, too, if you remember. It got softmods, just as the Wii did, though - as well as cheap hardware to unlock it (Pandora's Battery), just as the DS did (R4DS).
They still are developing homebrew and tools for the 3DS, and it's not slowing down, so once the 3DS, like the others, becomes unlocked, we will see a renaissance develop just as with the other systems.
re: publication of 3DSFT through official means on Nintendo eShopMiniMacro wrote:Well, maybe we could go to one of the indie publishers like Nicalis and with JSR's permission, get it published on the 3DS shop?
No. There is little to no chance of Nintendo's indie vetting process passing a homebrew, Linux-based, relatively bloated, quick-and-dirty hack-job of a port of a QT wrapper for an MFC Windows application to the eShop. (No offense to cpow/FT devs and contributors. Your efforts are well appreciated!)
For starters, it runs in a Linux operating system, replacing the ARM11 application kernel! It disrespects the APIs and ABIs provided by Nintendo, and the limits set by their SDKs, in order to take full advantage of the hardware.
I don't think it would be a bad idea to publish a music-creation tool based on FamiTracker, but it would need to respect the GPL, which may be impossible to do in "by-the-books" official 3DS development, as it will be linking in proprietary, but necessary libraries for interfacing the 3DS, and leaking even the symbol names but keeping the 3DS libraries secret (as is usually done under the 'OS libraries' provision/memorandum-of-understanding, which protects Windows-based and other proprietary-OS-based GPL applications) may constitute a breach of NDA.
The GPL does not, to my knowledge, have provisions to protect NDA-encumbered system libraries.
I'm also slowly working on a game based on a GPL-licensed engine, and I plan on releasing the game on the 3DS eShop in the future, possibly. In order to do so, it will take a lot of jumping through hoops, and some techniques and loopholes in building with their SDK, which will not work with this project.
Finally, the FamiTracker UI has a bit of a learning curve to adjust to, plus the concepts of the effects column, volume and note balancing, and the restrictions of NES music creation, might be lost on a significant contingent of eShop users, who would complain about buying an app that didn't work for them. I'd recommend making a more user-friendly music tool which makes "8-bit" or "chiptune-like" music like, if not directly based on, Famicom's hardware.
re: cpowcpow wrote:Whatever I can do to help I certainly will if I can. But lacking a 3DS I probably can't. PM me if you want.
As I mentioned above, you can certainly help!

If you can build it on Linux at all, it will be largely compatible. Perhaps a couple ifdef's could be used to separate a 3DS-compatible build from a desktop-compatible build, mostly for hotkeys and input.
If you want to test on something a little closer to the hardware, then you can use qemu.
Also, a 2DS (not the original DS or DSi family of systems) is compatible, and can be used instead of a 3DS, as well as any 3DS-family hardware with homebrew support (which is all of them, so far).
re: re: header file casingcpow wrote:Also, RE the header file casing. Yes, I have provided patches to JSR for all of that but I don't think those patches are released since I haven't seen the source for 0.5.0.
It's not a major issue, I just start a build, find a missing library/header in the build error log, and rename something or change the header to match casing.
Sometime prior to the first major source release, I'd go about either making all the source filenames lower-cased, and edit the header includes to match, or just editing the header includes to match existing casing.
re: static Qtcpow wrote:I wouldn't recommend doing Qt statically. From what I remember when I tried it eons ago its performance was horrid and it wasn't as capable. Plugins don't come along for the static ride. Memory has faded a bit but the experience wasn't memorable in a 'good' way.
That's as good a reason as any.

I just figured having a single executable would make things easier for those who already have a Linux environment on their 3DS and don't wish to waste the space.
Instead, I may make it use a self-extracting archive containing the necessary Qt libs and the executable.
Qt-FT for 3DS progress:TODO so far:- Build Qt for ARM, and install Qt for i386.
- Build Linux for the 3DS. The post on GBATemp makes it almost dead-simple.
- Get Qt-FT building on my desktop, and begin fleshing out the UI.
- Build QT-FT for the 3DS.
On the roadmap:Once I feel QT-FT is mostly feature-compatible on the 3DS, and the UI is prepared, I may discontinue developing it (small fixes aside) until 0.5.0's final release/GPL source release, and until then, work to incorporate 0CC-FT additions and code structure, since it is generally cleaner and more widely compatible than stock FT.
Feature-creep goals:Perhaps in the distant future, I'll mod the Linux framebuffer driver, scratch up a kernel module and user-space support commandline tool, and add a /sys/ node, to support the 3D display, slider and 3D LED.
Just for a visualizer, among other optional visual spice. Working in 3D will kill your eyes, so the 3D will be disabled while not playing.
Closing words:I will be opening a channel for discussion and coordination for 3DS-QtFT (working title) on the Famicommunity (originally FamiTracker Talk) Discord server, on the #famitracker-dev channel, here:
https://discord.gg/0TKgUmSjoOFCLd3v