49 Reply by alexras

(38 replies, posted in Nintendo Handhelds)

nitro2k01 wrote:

I don't really have any good suggestions, but since I've written my own file manager, I can help you a little with hints about hings you can error cherk when loading files.

All of this can be summarized as, check that the file length is correct. You should get $e0, $ff when you have output exactly 32768 bytes, not more, not less. What's below are just methods to detect errors as early as possible.

1) Check that block switches ($e0) are valid. The parameter must be > (the current block) and < $1f. Or constants $f0/$f1 for default instr/wave, or $ff for EOF.
2) Check that there's actually a block switch within the 512 bytes of a block. If not, the file is corrupted somehow.
3) Check each block against the values in FAT. If you don't have a 1:1 match, either the FAT or the contents of the file are corrupted.
4) Another thing you can check, which is the only thing in this list that I don't check in LittleFM, is that the default instrument/wave commands are at output positions that are actually possible. I.e. the instrument command can only output data at positions $3080, $3090 and following aligned addresses. Likewise, waves must be written to $6000, $6010 and so on.

At the very least, check 1 and 2.

Thanks for the tips! I'm definitely asserting correct file length as well as checking for 1 - 3. 4 should be easy enough to check.

Go to forum: Nintendo Handhelds

50 Topic by alexras

(38 replies, posted in Nintendo Handhelds)

I'm in the middle of developing a suite of scripts for manipulating LSDj .sav files - merging songs together, extracting instruments from one song and sticking them into another, etc. It's called lsdj-sav-utils, and can be found here.

The code is to the point where it can load and save data from .sav files (not guaranteeing that it's bug free, of course).

I don't want to waste my time writing scripts that nobody's going to use, so I thought I'd try to put this Google Moderator board for you all to post suggestions for script functionality (I've already posted a couple of starters) and to up-vote others' suggestions that you like. I think doing it this way might be easier than a thread with a bunch of "+1!" messages in it.

http://goo.gl/mod/IILw

Looking forward to hearing your suggestions. If you think Google Moderator sucks and you want me to set up with an alternative service, please say so. If enough of you complain, I'll switch it over.

Go to forum: Nintendo Handhelds

51 Reply by alexras

(42 replies, posted in Nintendo Handhelds)

OK, loading and saving code is written and I've refactored it to decouple blocking and de-blocking from compression and de-compression, but still doesn't quite work yet. I'm going to keep debugging it now; it's made slightly complicated by the fact that LSDj doesn't zero blocks before writing to them, so black-box byte-by-byte checking isn't that effective.

Anyway, I'll keep you all apprised.

Go to forum: Nintendo Handhelds

52 Reply by alexras

(42 replies, posted in Nintendo Handhelds)

Alright, the piece that reads the .sav file and splits it into pieces by instrument, pattern, etc is written (not tested yet though).The piece that takes those pieces and turns them back into a raw stream of bytes is written as well. Now I just have to write the thing that converts that raw byte stream back into blocks and the thing that produces a proper .sav file from a set of projects and the hard part will be done.

Go to forum: Nintendo Handhelds

53 Reply by alexras

(42 replies, posted in Sega)

ui wrote:

mister Shiru!...i tried Vortex Tracker II and works super fine. No lag or anythign wrong with the sound...

Is there is any kind of special config or something?

Have you tried increasing your buffer size? See this thread: http://chipmusic.org/forums/topic/2548/ … e-problem/

Go to forum: Sega

54 Reply by alexras

(42 replies, posted in Nintendo Handhelds)

Alright, I've got the .sav loader written; the .sav writer should be pretty easy to write now that I know what all these various data structures contain and what they're for. I augmented the documentation on the LSDJ wiki somewhat to explain things like allocation table layouts, etc. Lots of time with a hex calculator. Oy.

The next thing that I need are test files. If you have a complex LSDJ .sav (with tables, waves, etc. etc.) it would be great if you could PM me with a link to it. To sanity check this thing, I want to read a complex .sav in and then write it out again and make sure I've got the same file. It will also help me decipher things like which fields correspond to what for which instrument types, etc.

Go to forum: Nintendo Handhelds

55 Reply by alexras

(42 replies, posted in Nintendo Handhelds)

http://code.google.com/p/lsdj-sav-utils/

Had to stop working on this for the day, but hopefully it will be ready to load and save LSDJ .sav files in a couple more days. Then I'll start working down the "wish list".

Go to forum: Nintendo Handhelds

56 Reply by alexras

(42 replies, posted in Nintendo Handhelds)

It should be easy enough to de-duplicate instruments; there's a pretty well-formed equality condition between them I think.

lsdj2xml looks legit, but it hasn't been updated in a long time (personally, I wouldn't have chosen to write it in C, but that's me). If it works though, that's great.

I think the idea of .sav to MML and back again, while interesting, is a bit heavyweight for what we want to accomplish here (unless someone please oh please has an MML grammar, tokenizer, etc just lying around). I think that lsdj2xml has the right idea in compiling it back and forth from some intermediate representation and funging it in that way.

@gizmo, if you haven't already started working on this, would you object to my starting a project in Google Code and writing the whole thing in Python? Python makes me less swear-y than C does any day, esp. for things like this that aren't exactly performance critical.

Go to forum: Nintendo Handhelds

57 Reply by alexras

(45 replies, posted in Software & Plug-ins)

To avoid cluttering this thread with "This new thing has been implemented!" posts, I've started a devblog.

http://mml-tracker.blogspot.com/

Check that out if you're interested in following updates on the software.

Go to forum: Software & Plug-ins

58 Reply by alexras

(45 replies, posted in Software & Plug-ins)

Shiru wrote:

Chip emulator runs in a thread, every N samples (44100/update rate) it calls a function which updates chip registers. You can't just communicate with an emulated chip like you can with a real one, because emulation is not real-time.

Ah, that makes perfect sense.  Thanks, Shiru! Out of curiosity, what library, if any, did you use for TFM's YM2612 output?

Go to forum: Software & Plug-ins

59 Reply by alexras

(45 replies, posted in Software & Plug-ins)

Thanks for your interest!

Making mml-tracker output something that xmpck will recognize should be pretty straightforward. The real challenge here is getting the "it plays a sound when you enter a note" functionality working across platforms. I may just punt on that until I have a complete working copy that dumps MML and then add platform-specific playback features as I figure out how to get it to work for each platform. I'm playing with getting this to work with Blargg's audio libraries so that I'll have a good base set of platforms, but I'm not sure how well playing a VGM file, for example, works for realtime note playback. I suppose it depends on how fast I can construct VGM files in memory(?)

Does anyone know how other trackers (TFM, FamiTracker, etc.) handle this? Presumably they just communicate with a chip emulator and send "note on" and "note off" events to it?

Go to forum: Software & Plug-ins

60 Reply by alexras

(45 replies, posted in Software & Plug-ins)

Trust me, It's still going on. Work is kind of crazy right now and I'm still trying to figure out the API to the audio libraries. As soon as anything substantial is done, I'll let you all know.

Go to forum: Software & Plug-ins

61 Reply by alexras

(45 replies, posted in Software & Plug-ins)

Hmm ... that approach also makes a lot of sense. In order for MML generation to work, I think a similar approach might be necessary (encapsulate the platform-specific MML outputting logic along with sound generation, instrument editing, etc.) For something like this where I'm doing it in my spare time, I'm not necessarily going to go for full modularity, but having each platform's logic conform to some well-defined interface is definitely a must.

Go to forum: Software & Plug-ins

62 Reply by alexras

(45 replies, posted in Software & Plug-ins)

Basic idea is as follows: there are two "rows" to the tracker's UI. The first UI is the sequence list and the instrument list. Each sequence is defined as a pattern per channel. Instrument list is just a number followed by a user-defined name (and possibly the name of the chip you're using); double-clicking on the instrument in the instrument list brings up an instrument editor. Second "row" is the tracker grid. The number of channels and the instrument editor change based on the chip being tracked.

Presumably the 4op configuration will be handled in the YM2612's instrument editor.

I'm slowly but surely figuring out Qt. This is my first serious foray into GUIs; I've worked with MVC frameworks in a web setting, but I mostly spend my time on the command line and I'm starting to figure out why :-D

Go to forum: Software & Plug-ins

63 Reply by alexras

(45 replies, posted in Software & Plug-ins)

Here's a link to the Google Code repository I'll be holding the code in. You can keep up-to-date on changes by looking at commits for now. If anyone wants to contribute, feel free to fork a repo and send me pull requests when you've got something to submit.

http://code.google.com/p/mml-tracker/

Go to forum: Software & Plug-ins

64 Reply by alexras

(45 replies, posted in Software & Plug-ins)

spriteful wrote:

Dumb question- do you think your planned software will be able to play each note as it is entered?

Hopefully.  I'm sure I can figure out how other trackers are doing it with a given library by just looking through source.

Phase 0 of development really is going to get a usable GUI that will spit out MML. The GUI programming and the up-front design work is probably going to be the most time-intensive.

Go to forum: Software & Plug-ins