Offline
Los Angeles, CA

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.

Offline
Los Angeles, CA

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".

Offline
Unsubscribe
alexras wrote:

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".

You are a god among men. Like Jesus, but real.

Offline
Brooklon

HOLY CARP. You are amazing. Looking forward to trying it out.

Offline
sweden
herr_prof wrote:
alexras wrote:

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".

You are a god among men. Like Jesus, but real.

THIS!

Offline
Los Angeles, CA

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.

Offline
Matthew Joseph Payne

holy wow, how did I miss this when you originally posted it?

I'll gladly come up with a test file for you, too.

Last edited by kineticturtle (May 4, 2011 1:42 am)

Offline
Los Angeles, CA

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.

Offline
Stockholm
xero wrote:

it would be nice to at least be able to hold the copy paste data even when switching songs.

It does this already.

Offline
Los Angeles, CA

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.

Offline
Los Angeles, CA

For those who are curious; four years later this finally became a thing: http://chipmusic.org/forums/topic/16398 … sav-files/