Square SNES SPC Engine

[Disch]

@Bregalad:

Yes there are many features that different engines offer.  I'm doing my best to abstract them to a common interface.  For future games down the road I might have to expand the interface to add more features to support some games.  But the grunt of the loading/saving work will be done by the Lua.

I'm aware that game engines may not be compatible.  And there are ways to detect that from the Lua.

I've already worked most of this out.  I don't expect it to make much sense until I finish and publish the info.

Skepticism is good.  I realize it's not a simple task.  But I do feel like it's one I have the ability to tackle.  I guess we'll see how well it turns out.  =P


@lytron:

I'm not getting into anything fancy yet.  I'm just focusing on loading/playing SoM's music right now (not even editing yet).  This will get me the groundwork for the actual editor.  I might have to tweak a few things in the editor to add features for other games, but I think once it gets 3 or 4 games under its belt it'll be dynamic enough for anyone to write Lua for it.


And yes I do have plans for editing the brr sample data.

[lytron]

@Bregalad:
Yes there are many features that different engines offer.  I'm doing my best to abstract them to a common interface.  For future games down the road I might have to expand the interface to add more features to support some games.  But the grunt of the loading/saving work will be done by the Lua.

I'm aware that game engines may not be compatible.  And there are ways to detect that from the Lua.

I've already worked most of this out.  I don't expect it to make much sense until I finish and publish the info.

Skepticism is good.  I realize it's not a simple task.  But I do feel like it's one I have the ability to tackle.  I guess we'll see how well it turns out.  =P

I'm excited, despite all my skepticism.
Can you estimate how long it will take you to release the first screenshots/rough demos?

I think you can do this if you (and we) accept from the start that there will me songs that won't be perfectly emulated. If a sound engine has a certain feature that the others don't cover, than your program could examine the sound data and look up if/when it's used and than replace it with something comparable.

I'm not getting into anything fancy yet.  I'm just focusing on loading/playing SoM's music right now (not even editing yet).  This will get me the groundwork for the actual editor.  I might have to tweak a few things in the editor to add features for other games, but I think once it gets 3 or 4 games under its belt it'll be dynamic enough for anyone to write Lua for it.

And yes I do have plans for editing the brr sample data.

Pardon my assholiness, but the sample thing was a catch question.
Because, well, then you have to prepare to wade kneedeep through games' ASM.

Each game does not only consist of SPC-programs, but a number of supporting subroutines on the ASM(= 65816 = 5A22)-site. The "change music to ##"-subroutines are the least part of it.
In case of Ihatovo Monogatari, there is (have I mentioned it before here?) a subroutine that builds up the BRR sample "palette" and transfers it. Each sample has a 4-byte-header that tells the transfering subroutine how many bytes have to be transfered to the SPC. Simply replacing that sample with another one without changing the header can lead to yet unknown, disastrous results.

I can offer you what I found out about these ASM-sound-subroutines, that's not the problem. My point is, as I mentioned before: You have to do this for each game you want to add, which additionally would be really time consuming (apart from the SPC stuff).

Again: I really appreachiate your plans and don't doubt your efforts, but I don't see a solution to these challenges that won't let this end up being your lifework.

[Disch]

Can you estimate how long it will take you to release the first screenshots/rough demos?

It depends what happens with my real life job, really.  I'm on the verge of it.. umm... "changing".  If that happens I'll have more free time.

Though I'm not going to give a deadline or even an estimate, as I find that just gives me stress and I never seem to meet them anyway.  =P

I don't have anything graphical yet... as I have just been focusing on writing the lua, getting it interpretted, and getting the song loaded.  I'm currently working on loading the score data.  Once I have that, I'll work on actually playing it back (to confirm it's loading properly)... then I'll start making a GUI.

I think you can do this if you (and we) accept from the start that there will me songs that won't be perfectly emulated. If a sound engine has a certain feature that the others don't cover, than your program could examine the sound data and look up if/when it's used and than replace it with something comparable.

The editor is going to use its own "internal" music format that doesn't care about any game's format or features.  It'll basically be an extremely generic spc player/editor.

The Lua will do everything regarding interacting with the ROM.  It'll pull out the brr data, and parse the score data and translate it to equivalent 'internal' commands.  This I think is what is leading to the heavy scepticism, maybe you guys are thinking the Lua script is just a series of offsets -- or some magical boilerplate that tweaks a few load settings to switch which load-routine the editor uses for this particular ROM.  It's a lot more than that.  The current Lua script for SoM is 327 lines, and that doesn't include ANY save information... and only has info to load like half of the commands.  I expect the final SoM Lua to be over 1000 lines.

Adding new Lua scripts will be non-trivial.  It'll be a daunting task... I'm not saying that anyone can just slap a few things together and add support for a new game.  They'll effectively have to code an entirely new program to load/save music data.  But... once they do, the game will conform to a feature-rich and easy to use editor (that's the idea anyway).

So while it still isn't easy to add new games... it "easier".  The idea is that writing 1000 lines of Lua is a lot simpler than writing an editor from the ground up.

With the way the Lua is set up... all it takes to see if a game supports a certain feature or not is to check for the existence of a callback function in the script.  If it doesn't exist... the feature isn't supported... and the editor can prevent you from using that feature when running with that particular Lua template.  If you import another song from another game... it can scan it for all the features it needs, probe the Lua to see which ones aren't supported... and prompt the user on what they want to do about it.

Pardon my assholiness, but the sample thing was a catch question.
Because, well, then you have to prepare to wade kneedeep through games' ASM.

One of the assumptions the editor [currently] makes is that the brr data is stored contiguously and uncompressed.  Since it's already sort of compressed... I thought it was a safe assumption that games won't try to compress it further.  And breaking it apart and storing it in different places in the ROM would be a waste of space and effort... so I thought it was also a safe assumption to do that.

Everything else is in the Lua.

In case of Ihatovo Monogatari, there is (have I mentioned it before here?) a subroutine that builds up the BRR sample "palette" and transfers it. Each sample has a 4-byte-header that tells the transfering subroutine how many bytes have to be transfered to the SPC. Simply replacing that sample with another one without changing the header can lead to yet unknown, disastrous results.

So are you saying it's a 4-byte header followed by the entire sample?  Or that each sample consists of multiple such blocks and it may have to load 4 or 5 headers/blocks to get the full sample?

The former is pretty typical and would be supported by the editor as it is currently planned.

The latter would not be and would take some changes to how brr would be saved/loaded (I'd have to go back on some of my earlier assumptions).

Again: I really appreachiate your plans and don't doubt your efforts, but I don't see a solution to these challenges that won't let this end up being your lifework.

Adding support for every game under the sun would take forever.  Fortunately that's not my goal.  My goal is to be generic enough so that additional games can be added with reasonable effort.


EDIT:

The current SoM Lua for those interested:

http://codepad.org/yYrNJFBn

[lytron]

The editor is going to use its own "internal" music format that doesn't care about any game's format or features.  It'll basically be an extremely generic spc player/editor.

The Lua will do everything regarding interacting with the ROM.  It'll pull out the brr data, and parse the score data and translate it to equivalent 'internal' commands.  This I think is what is leading to the heavy scepticism, maybe you guys are thinking the Lua script is just a series of offsets -- or some magical boilerplate that tweaks a few load settings to switch which load-routine the editor uses for this particular ROM.  It's a lot more than that.  The current Lua script for SoM is 327 lines, and that doesn't include ANY save information... and only has info to load like half of the commands.  I expect the final SoM Lua to be over 1000 lines.

The code you posted below isn't the complete program, is it? You are mentioning some "Splisch". Is Splisch the actual Editor, and the posted thing the translator from SoM to Splisch?

Adding new Lua scripts will be non-trivial.  It'll be a daunting task... I'm not saying that anyone can just slap a few things together and add support for a new game.  They'll effectively have to code an entirely new program to load/save music data.  But... once they do, the game will conform to a feature-rich and easy to use editor (that's the idea anyway).

So while it still isn't easy to add new games... it "easier".  The idea is that writing 1000 lines of Lua is a lot simpler than writing an editor from the ground up.

Okay, now I got that, and now this makes a whole lot more sense. And, as long as you add whatever SPC engine I dig out, I'm totally fine with it.

It's more like a "Once and for all"-program that "overtakes" the providing of the GUI and so on and only leaves it to the other programmers to write the game-specific "adapter". Cool stuff.

EDIT: MIDI SUPPORT!!!! WE NEEDZ MIDDI SUPPUUURTT!!!!1!

With the way the Lua is set up... all it takes to see if a game supports a certain feature or not is to check for the existence of a callback function in the script.  If it doesn't exist... the feature isn't supported... and the editor can prevent you from using that feature when running with that particular Lua template.  If you import another song from another game... it can scan it for all the features it needs, probe the Lua to see which ones aren't supported... and prompt the user on what they want to do about it.

Well, I don't know anything about Lua, so I just believe you that it is that simple. I'm really excited to see the first versions of this!

One of the assumptions the editor [currently] makes is that the brr data is stored contiguously and uncompressed.  Since it's already sort of compressed... I thought it was a safe assumption that games won't try to compress it further.  And breaking it apart and storing it in different places in the ROM would be a waste of space and effort... so I thought it was also a safe assumption to do that.

Everything else is in the Lua.

So are you saying it's a 4-byte header followed by the entire sample?  Or that each sample consists of multiple such blocks and it may have to load 4 or 5 headers/blocks to get the full sample?

The former is pretty typical and would be supported by the editor as it is currently planned.

The latter would not be and would take some changes to how brr would be saved/loaded (I'd have to go back on some of my earlier assumptions).

As far as I saw it in the game's code, the samples are in one piece. Yet it will be another quite big bit of work to make new samples fit in. The headers for the additional samples have to be calculated, the sample address tables have to be moved to another section of the ROM (because they won't fit anymore in the position they are originally in), the addresses of the address table has to be replaced everywhere and so on and so on...
Well, yeah, that's a bunch of work. But, as you mentioned, as long as you only do single games and not the whole SFC catalogue, this can be done.

The current SoM Lua for those interested:

http://codepad.org/yYrNJFBn

I'm thinking about line 166 and if these note durations have to be editable. These values are hypothetical editable in the Original SoM engine, but I do not know if there is an actual way to edit them with the sound engine as it is at the moment. So, I think, you can leave them fixed for now (and maybe a long, long time. ).

[Disch]

The code you posted below isn't the complete program, is it? You are mentioning some "Splisch". Is Splisch the actual Editor, and the posted thing the translator from SoM to Splisch?

No that was not the whole code.  The code I posted was just the Lua.  IE: just the details specific to Secret of Mana.

"Splisch" is the editor.  It calls into that Lua script to tell it to load songs.  The Lua then calls back several functions to tell Splisch where the data is and then eventually what to do with it.

I haven't outlined the process in detail yet (because it's still fluid).  But I'll eventually create a big doc explaining the process.

It's more like a "Once and for all"-program that "overtakes" the providing of the GUI and so on and only leaves it to the other programmers to write the game-specific "adapter". Cool stuff.

Yeah... That's the idea.  Generic enough to be applicable to any game... but you need to have a mini-program/adaptor written up to get game support.

EDIT: MIDI SUPPORT!!!! WE NEEDZ MIDDI SUPPUUURTT!!!!1!

I might do Midi importing/exporting.... but that's for waaaaaaaay in the future.

Waaaaay in the future.  That's like step 54.  I'm still on step 3.

Well, I don't know anything about Lua, so I just believe you that it is that simple.

Code Select Expand


lua_getglobal(L,"func_to_save_vibrato_to_rom");
if( !lua_isfunction(L,-1) )
{
    // Lua has no code to save vibrato commands.
    //   therefore this game does not support vibrato
}


As far as I saw it in the game's code, the samples are in one piece. Yet it will be another quite big bit of work to make new samples fit in. The headers for the additional samples have to be calculated, the sample address tables have to be moved to another section of the ROM

We might be talking about different things here.

There's a fixed amount of free space in the ROM for certain data.  In the Lua, I refer to this as the "workspaces" -- you can see this at the top of the Lua script I linked before.  It outlines the blocks of space in the ROM, how big they are, and how they're used.

Ultimately the number of songs/samples you can have is limited to the size of your workspaces.  The editor won't allow you to just endlessly add new material.

When you asked about editing brr I though you were just talking about like importing a wav file and converting it to SPC's brr format.  Which I do intend to support.

I'm thinking about line 166 and if these note durations have to be editable. These values are hypothetical editable in the Original SoM engine, but I do not know if there is an actual way to edit them with the sound engine as it is at the moment. So, I think, you can leave them fixed for now (and maybe a long, long time. ).

Yeah that was just temporary.  I need to come up with the interface for making that editable.

[lytron]

No that was not the whole code.  The code I posted was just the Lua.  IE: just the details specific to Secret of Mana.

"Splisch" is the editor.  It calls into that Lua script to tell it to load songs.  The Lua then calls back several functions to tell Splisch where the data is and then eventually what to do with it.

I haven't outlined the process in detail yet (because it's still fluid).  But I'll eventually create a big doc explaining the process.

Somethin' like a blog, with status updates, and RSS feed, and comment functions, and stuff? 
With what do you write the editor?

I might do Midi importing/exporting.... but that's for waaaaaaaay in the future.

Waaaaay in the future.  That's like step 54.  I'm still on step 3.

Step 53 are MOD-/IT-Files, I guess.
I will, by the way, try to write something together that you can implement a sample-exchanger in Ihatovo Monogatari whenever you are ready. I think that is something I can do as soon as I find the (half) hour to do it, the whole program stuff is already disassembled (it is nothing SPC-related, it's of course ASM-based).

Code Select Expand


lua_getglobal(L,"func_to_save_vibrato_to_rom");
if( !lua_isfunction(L,-1) )
{
    // Lua has no code to save vibrato commands.
    //   therefore this game does not support vibrato
}


Ah, I guess I got it now. You create a certain stack of functions each "adapter" has to "translate", theoretically, and if there is something it cannot translate, you leave this if{}-clause empty, and it automatically means that it is not support (kinda "If it isn't on the shelf, then it's not in stock").

We might be talking about different things here.

There's a fixed amount of free space in the ROM for certain data.  In the Lua, I refer to this as the "workspaces" -- you can see this at the top of the Lua script I linked before.  It outlines the blocks of space in the ROM, how big they are, and how they're used.

Ultimately the number of songs/samples you can have is limited to the size of your workspaces.  The editor won't allow you to just endlessly add new material.

Nope, that's for sure, but AFAIK it leaves you a whole lot of workspace to do so.

Again I take Ihatovo Monogatari (because it's the only ROM I know so far):

The ROM is $10000 bytes in size, this leads to thirty-two banks (IM is LoROM, SloROM, so it is bank $0 to $1F).
This leaves another $10000 bytes open, the banks $20 to $3F. And, as I know that the address table of the samples has 24-bit-addresses, you can easily append samples to it, change an address in the table, and done.

Correct me if I'm wrong, I haven't tested it yet.

Yeah that was just temporary.  I need to come up with the interface for making that editable.

This depends.
If you want to *generally* edit it: These values are at $1526 onwards in SPC RAM. I expect them to be in exactly this shape without any compression in the SoM ROM somewhere, I guess they are transfered with the SPC sound engine. So, if they have to be changed overall, you can do it.
If you want to be able to change them while the program is in use... I guess that might be hard, because you would have to rework the whole engine.

But right now it came to my mind: maybe it's not even necessary. The smallest time-unit are 3 and 4, so most possible note duration values can be constructed out of combinations of multiple 3s and 4s, so the inaccuracy of the time will be insignificantly minimal.

[danseenwabbitz]

It seems like this project is dead...

I'm also looking into a "universal format". However, moving songs from PS1/GC to SNES isn't possible without cutting polyphony. https://github.com/jimbo1qaz/bms-format (moving rather slowly).

[Bahamut ZERO]

It seems like this project is dead...

I'm also looking into a "universal format". However, moving songs from PS1/GC to SNES isn't possible without cutting polyphony. https://github.com/jimbo1qaz/bms-format (moving rather slowly).

Thanks for posting in this thread to bring it to the first page. I've been looking for info like the kind in this thread for AGES. And while it's based on a newer version of the sound engine than the game I'm working with (FF4), it's a great read nonetheless.