1

(3 replies, posted in Nintendo Handhelds)

Back in 2009, a user (abrasive) on an old chiptune site (8bc) posted a Perl script which overwrote both the frequency table and the note name table in an LSDJ ROM. It allowed LSDJ users to break out of the 12TET that LSDJ uses by default, but since the script was written, the LSDJ code changed, and the script broke.

With the help of the LSDJ developer, I have managed to fix the script so that it works with current versions of LSDJ, and I have uploaded it to Github: https://github.com/Dmac9244/LSDJ-Tune.

I hope someone finds it useful; I'm really excited myself to start composing something in Bach-Lehman temperament, and I've already re-recorded all my old chiptunes in it. The difference is slight but I feel that it really helps the chiptune feel more 'alive.' Maybe sometime I'll get a little more experimental, and see what crazy microtonal things I can do with LSDJ.

If anybody's interested, I managed to, in a twist of irony, git rid of everything but the clicks, and now I'm trying to figure out what I did that prevents the emulator from making the part of the sound that I actually want. It's better than where I was before, where I had somehow broken every channel but the wave channel, and that itself was making horrid noises and acting erratically.

Doctor Octoroc: unfortunately, I don't think there's a way to do that in LSDJ, though it's awesome that you've found a workaround. You're right; LSDJ will retrigger the channel whenever there's a new note in the track. I believe Deflemask doesn't always, because I remember trying it out once and having the Deflemask equivalent of the LSDJ L command (sweep frequency to note) affect the end of the old note instead of starting a new note and sweeping the frequency then. I'll look into that and the Teensyboy too; it would be good to have the option of MIDI, anyway.

herr_prof wrote:

If you look in sameboy, it has the ability to set the Gameboy model, what would be really cool is if someone could create a IDEAL MODEL so you can toggle between that ideal one and the accurate ones at choice.

I'd love to do that, but my coding skills aren't good enough at the moment to do something on that scale. For the moment, a proof-of-concept would work for me, and I could easily distribute my own sameboy - XQ audio version until either I figure out how to modify the sameboy code on a greater scale, or somebody else takes up that slack to add that toggle. I might work up the courage to ask the developer about it, and then I might be able to make some actual progress if they agree to help.

egr wrote:

Is the silky wave something you turn on or is it a straight up change? I see it mentioned but can't find an explanation.

As far as I can tell, the silky wave is a feature which the LSDJ developer toggles on and off for specific ranges of the wave channel. Looking back in the LSDJ change log, it seems that it is currently enabled for most, if not the entire range of the channel, and there is nothing the end user must do to enable it -- just download a current version of LSDJ which has it enabled for most of, if not the entire range.

herr_prof wrote:

Have you tried using later versions of LSDJ? The clicks have largely been mitigated with the new silky wave feature.

Fwiw id look at modifying sameboy, which is both super accurate and open source. They also plan on supporting multi-channel export.

I'm using the latest versions of LSDJ, but I'm still getting pretty annoying clicks. I'll try something a little less new since I'm running development versions rather than stable versions, and I'll look it up in case there's something I'm missing that I need to enable or something like that. I never used older versions of LSDJ, so maybe I'll go download an older one just to see how bad the clicky could be.

And thanks for the suggestion. I was referring to sameboy (and mgba) above, I just wasn't sure how appropriate it was to mention them specifically. Sameboy's code makes a little more sense to me, it would just be nice to have documentation on it (or any open source project, I guess) so new developers don't have to spend days just decoding what other developers spent years writing just to make modifications like this.

And it's good to hear that other developers are doing multi-channel recording, too. It's an amazing feature for chiptune artists and it annoyed me (for whatever little reason) more emulators didn't support it.

Edit: I did take a look at older LSDJ versions (going back to 2.5.7) and found that indeed, the click was much worse. I still want to eliminate it altogether at the emulator level, but it's nice to know that something can be done about it at the software level.

I was wondering how possible it would be to 'fix' the Game Boy click sounds on channel 3 by modifying an accurate emulator to not make them. I understand there are ways to hide the clicks, but I would also like an option just to... not have them.

I already tried looking at the source code for an existing GB(A) emulator to see if there was a simple way of doing this, but it seems my programming knowledge is too limited to understand how it works without help. If it seems like a feasible idea, I'd love to pursue it further, but if not, I guess I'll just have to resort to hiding the clicks.

As I understand it, the click is a glitch that happens when the GB has to write a new sample over the old sample. The GBA solves this problem by having 2 banks for samples (rather, 1 bank which is twice as large but can be split in half), and it just switches to the other bank instead of overwriting the current bank. But it seems that current emulators don't make use of this feature when running lsdj, unless there is something I am missing about running lsdj on a GBA (via PC emulation).

I'm thoroughly over my head on this, but it seems to me there should be a way to do this, and I'd like to find it so we can have a blissfully click-free wav channel.

Update: I have taken a closer look at the source code for a different emulator, and it is starting to make sense to me. It seems like I might be able to layer the GBA technology behind the GB emulation code so that on the surface, the emulation doesn't change, but behind the scenes the GB emulator is running GBA style code. We'll see how this works as I continue analyzing the source code.