Searching for N-SPC & SPC700 info

[softglow]

I'm trying to track down everything known to the romhacking universe about producing SNES sound.

I've found some stuff that seems pretty in-depth already: Kejardon's notes, particularly SPCDisasm; MenTaLGuY's N-SPC reference; a whole lotta background info on the SNES sound in general (tracks, voices, DSP, BRR compression, etc.); and byuu's bass.

Am I missing anything interesting?  Has anything more been done to make it easier to edit the super metroid music?  Any tools that run on linux are especially interesting.

(I'm currently in the exploration phase on this so I don't know what'll come out of the process.  No guarantees whatsoever, but I'm sure you're all used to that.)

[Blarget2]

http://ekid.nintendev.com/xms/

[softglow]

http://ekid.nintendev.com/xms/

Aha. I heard of xmsnes but assumed it was another full emulator.  Thanks!

[DSO]

Has anything more been done to make it easier to edit the super metroid music?  Any tools that run on linux are especially interesting.

No "tools" specifically for Super Metroid. I use snesbrr to compress .wav files into the .brr format if I want custom samples, though often I just use a hex editor and find already compressed samples from other games. Then I use notepad to write out a text file with the music sequence data, which I then insert with xkas. It's a long, slow process for anything but the most basic songs. I have all the knowledge that one would need to write a music editor, but I don't know any programing languages (other than how to program for the SNES, lol).

Maybe I should write an SNES "game" that lets you write compilable music files in an emulator and saves them as the .srm. Then just rename and patch...
Nah, that's crazy.

[softglow]

Found another helpful one: NSPC.txt which is an IRC log of MathOnNapkins explaining all of the SPC stuff, including locating it in the SM ROM.  Good news, this is all starting to make sense.

Which means that it looks like what I want to do is create a language to write n-spc commands mnemonically (i.e. "rep 4 some_label" rather than "$0004 $5CCA"), which you then have the option to turn into either an spc or asm file.  First pass will probably require you to fit the new data in the same space as the old, or else repoint your rom and rebase the asm, but ultimately I'd like it all integrated so that you hand in a rom and get an asm that will probably work (either it follows an existing repoint, or makes a new one, if it has to).

Does that sound sensible and possible, or more like insane babbling?

[DSO]

It's saner than writing a rom so you can write and save music files with an emulator, for what that's worth...

Personal experience from writing out the ASM files by hand has given me a few ideas as to how I'd want the music editor organized. I'd be interested in testing and giving some detailed feedback on whatever you create here.

[softglow]

Before I had finished reading a bunch of stuff, I sketched out this idea like so:

song red_brinstar
      audio bank 1f
   channel 0 with
      instrument 1e
      volume 80 ; percent
      center c3 ; midi tone
      tempo 138 ; bpm
      cutoff 95 ; percent
   noteseq intro
      F _/2 E/2 A ; 4th note, 8th rest, 8th note, 4th note
   noteseq lead
      ... ; need note modifiers too.
      ... ; v(1f) for volume, #/##/b/bb/n for sharp/flat/natural,
      ... ; p(-6c) for panning, wait(x), any other insns
   ; more noteseqs, then:
   track
      intro    ; named noteseq, played once
   @main      ; just defining a label
      lead * 4 ; repeat this section 4 times
      ltail    ; lead->tail bridge and fill
      tail * 4
      tlead
      repeat @main ; jump back to label

I'm almost embarrassed to publish that now that I know more, but it gives you the idea of where I'd go left to my own devices.  (Also command line, because I am useless at windows GUIs, unless I require everyone to have GTK#.)

However, I'd rather it be useful to the wider romhacking community rather than something that only I end up knowing how to use, because I'm not a skilled composer (and especially not for trackers).  Which means I'm quite open to ideas, especially at this "haven't started coding" point where the design is easiest to change.  You can either throw them at me here, or email.

[softglow]

I only have a week of "can work on this as long as I want without my wife complaining" time, and it looks like I'm halfway through and still exploring options  :<_<:

The best language for this might be javascript/html, which is cross platform with a GUI built in, and has been growing interesting things like array buffers.

So, request is still open: I welcome the thoughts/drawings/etc. of anyone who has written or ported music.

[softglow]

Javascript audio and file access are in such infancy that I could maybe build something that worked only in Chrome with vendor prefixes.  Ugh.  I think I'll stick with my first plan, given that it's simpler in execution and done beats nothing.

I still have one lingering question, though:  Kejardon notes that instruments and samples are basically interchangeable when referring to the original ROM, because all instruments use only one sample each.  If I recalled that right, that means one instrument can be made of multiple samples?  How does N-SPC or the DSP decide which sample to use for the note, in that case?  Or is it the other way around, that you can configure one sample to sound like different instruments with sufficient trickiness with the ADSR register?