nesdev.org

On and off over the past few weeks I've been sketching out on paper what I think would be a workable NES tracker. I just wanted to get some opinion on whether people think it would be a worthwhile endeavour?

I'm quite excited about the idea but the one big "fly in the ointment" at the moment is the issue of being able to save your song.

I've worked out a reasonable memory map using the 8Kb SRAM to store a complete song but that presents problems. How do you save your song with a file name? How do you save multiple work-in-progress versions of the song?

I was thinking I could somehow utilise the save game feature of PowerPak but, to be brutally honest, I've never actually managed to get it to work (with a game ROM) despite reading the instructions several times

Of course, it would work fairly easily using Nestopia (or your emulator of choice, providing it supports SRAM saving) but it would be cool to run it on actual hardware.

Sounds good. People have made tools that run in the NES itself before. I think Celius made a level editor or something, and if I'm not mistaken Memblers did something too.

To make things easier, you could make a PC application to extract the relevant data out of the SRAM file. If you want to handle file names and such on the NES side, you can create your own pseudo file system, so that the names of the files, as well as their sizes, would be stored somewhere in the SRAM file, and then your PC application would extract the files out of your made up file system.

Well, if the main target is the Powerpak, maybe you should consider writing files to the CF card? This way the 8KB SRAM (or 32KB even) would be used for keepings the tune(s) in memory while tracking, and for saving files you'd use the CF card. Emulator users on the other hand could just use multiple save states. Or Lua scripting if you prefer FCEU.

That said, I've never been a big fan of this "wouldn't it be cooler to have the development environment actually running on a NES". I simply believe the least akward way of creating code and content for a console, which was never meant for creating new things on, is to use the most modern computer available to you. But never the less I look forward to trying out your results! :)

Making a tracker work with the NES controller doesn't sound more exiting to place .db statements in notepad to me. If the tracker is made to play files with a cool viewer and not to edit them then it's another story.

Bregalad wrote:Making a tracker work with the NES controller doesn't sound more exiting to place .db statements in notepad to me. If the tracker is made to play files with a cool viewer and not to edit them then it's another story.

Mr Cup-Is-Half-Empty....

I've always wrote NES music in a text file so I know what you mean. However, a native tracker offers some advantages such as live tweaking of sounds which could be useful both in a compositional use and a "live" use - give you the ability to "mix" a song in real time. Kind of like LSDJ....but on NES.

(Though I don't actually know much about LSDJ so I could be talking rubbish )

Bregalad wrote:Making a tracker work with the NES controller doesn't sound more exiting to place .db statements in notepad to me.

Do .db statements in Notepad:

1. allow starting playback at any point?
2. allow easy visualization of envelopes?
3. guarantee that your music bytecode is consistent?
4. allow viewing the relationships in time of commands across multiple channels?
5. run on the target platform, for composing in a handheld-based emulator while on the bus? (One can assemble a .nsf from source on a netbook but not realistically anything smaller.)

A tracker does.

If the tracker is made to play files with a cool viewer and not to edit them then it's another story.

The sort of "cool viewer" I'd appreciate would involve something like D-Pad Hero or DDR GB.

I'm working on mocking up the screen layout and will try to explain the approach/controls when that is done.

@Tepples: some interesting points there, some that I had overlooked or that won't work with the approach I've taken with the design. I've not gone for a traditional tracker where each pattern has the same number of steps for each voice but more based on a track->sequence format. I was inspired mostly by Ninja Tracker (C64) as it has a simple one-screen layout. I'll explain once I've got the screen mocked up.

Although I'm guilty of being one of the people who'd likely prefer a mouse and keyboard set-up, I've heard many others wish for an LSDJ equivalent NES tracker. People will be interested, there is no doubt about that!

I also have an idea that I think would be pretty awesome for a live play mode. It'd be a nice bonus that would set it apart from other trackers, and would be something that I'd certainly make use of. I'll shoot you an e-mail.

I guess I have the same opinion as Banamos. I would prefer a better tracker compatible in many OS than a tracker inside the platform itself since the inputs and screen estate are limited. With the current state of nes emulation, the needs to do it on the actual console directly become less an issue. I'm sure that even with the latest console, we don't make the music directly on it.

But this is just my personal opinion. It will still be interesting to see the final result for the technical aspect of it.

My opinion is identical to that of Bananmos and Banshaku, for what it's worth.

I'm not starting a line of code until I've resolved several issues.

The main one being just how someone would actually use the thing, especially in respect of being able to load/save their work. If I can't find a workable solution to that one, I don't think it's worth doing. I probably need to take a look at LSDJ and see how that's used (unless someone here can give us a brief overview of how loading/saving aspect is done, or indeed if it does at all?)

The other one is coming up with a clever data system for the note patterns. You have so little RAM to work with (in SRAM) that I see this as the biggest technical challenge.

As for the joypad input, I think I've worked out quite a good system for most of the editing but there are a few instances that I've yet to figure out.

The easy bit is the actual audio player so I'm not thinking about that yet.

As for using on *actual* hardware, I'm not suggesting that that would be the only use/reason for a NES tracker. Actually I was thinking more along the lines of being able to use it within an emulator. Seeing as there are so many good NES emulators, it might even be as platform agnostic as writing a Windows/Mac tracker that emulates NES audio. What about running it on, say, the iPhone NES emulator? Composing NES tunes in your pocket?

neilbaldwin wrote:http://dutycyclegenerator.com/#N-Track

That link supposed to go somewhere meaningful?

thefox wrote:

neilbaldwin wrote:http://dutycyclegenerator.com/#N-Track

That link supposed to go somewhere meaningful?

I thought I'd put the screen up there in the hope of promoting some discussion.

I was going to type up some design ideas but it was 1.00am and I was tired and also spotted a few holes in my paper scribbles so I went to bed instead.

neilbaldwin wrote:The main one being just how someone would actually use the thing, especially in respect of being able to load/save their work. If I can't find a workable solution to that one, I don't think it's worth doing. I probably need to take a look at LSDJ and see how that's used (unless someone here can give us a brief overview of how loading/saving aspect is done, or indeed if it does at all?)

I'm not 100% what you want to know here. If you mean how people save their work they've made on the actual game boy, there are game boy flash carts available with tools to extract the .sav file. (Much like how a .sav file would be put on a compact flash card with the powerpak). Or... they just use an emulator and get that save. So if you distribute an SRAM enabled rom, there's no issue there, as the powerpak or any emulator would accomplish the same thing.

If you mean how the program's save interface works, it allows you to save multiple files in the one SRAM file. At the bottom of the interface it tells you how many "blocks" you've used of the SRAM. The songs are shown in a list, with the number of blocks used by the song. When you save you're allowed to enter an 8 character filename to distinguish the files from one another. As well, it keeps track of how many times a file has been saved, and that number is displayed on the left of the file name, so if you have two versions of the same file you know which one was saved the most times. (which would usually be the most recent one) You can also delete and load files from this menu. Also, the file you're currently working on is stored uncompressed in 32kb, so you can turn the power off without saving and your song should still be there. (Wouldn't recommend that though, unless you're in a big hurry)

If you mean how the program compresses its save data, I can't be of much help : (

But rather than me ranting about the program, you REALLY should check out LSDJ yourself! The full (and save enabled) rom is only 2 USD, and the demo version (missing some features, and can't save) is free, so there's no reason not to check it out, especially since you want to make another native tracker using the exact same button layout. Or even if you don't want to mess with the rom, read the documentation pdf available on the site to see how it's laid out.

LSDJ has a great interface designed for an even smaller screen than NES has available to it, and the controls allow for much faster tracking than you'd think. I like it even better than some PC trackers. Even if you don't want to copy it completely, LSDJ has probably solved a lot of the problems you'll run into, especially those related to input/screen economy. The much smaller SRAM space NES has becomes a problem though, but with a similar compression scheme to LSDJ I think you could fit at least three small songs in 8k.