nesdev.com

Alright! Sorry about that, fixed the regression I introduced in the label sanitization, see OP for download. It isn't producing nonsense---what it is doing is replacing characters which are allowed in windows filenames with alphabetical characters. It used to be underscores, but then it is technically possible to cause more errors if somebody say named their file +++ and another file ++- or something, then it would have all been ___ and would have been treated as the same label. By replacing them with aaa and aab (example) you still get unique labels, consumable by assemblers. The mistake I made was that quotes need to be removed entirely. Teaches me not to regression test after a change! Haha!

As the sole copyright holder of the code in GGSound, I can assure you I will prosecute nobody if they use it. I don't think a full open source license is really necessary with this. This is a rather small, niche area of software with few (if any) people who would want to contribute to the project. A fair number of folks enjoy rolling their own anyway, that's part of the fun of this hobby.

A license is necessary in order to assure people that the first sentence is binding. It can be as simple as the WTFPL:

DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
Version 2, December 2004

Copyright (C) 2004 Sam Hocevar <sam@hocevar.net>

Everyone is permitted to copy and distribute verbatim or modified copies of this license document, and changing it is allowed as long as the name is changed.

DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

0. You just DO WHAT THE FUCK YOU WANT TO.

OP updated with GGSound distro attached with following changes:

-Duty cycles now support loop points for square waves.
-Added UNLICENSE.txt to state GGSound is public domain software. Use it however you like. Legal issues aside, of course it would make me happy to see GGSound in your credits regardless.

...Next update, I'm going to add support for duty cycles to the noise channel (I know that's not what it is called in the APU, but the same sequences within FT are applied, using just one of the bits). I realized suddenly GGSound has never supported that "buzz" capability of the noise channel, because I'd never thought to use it, myself. I'll try to get that in this weekend.

As promised, added duty/noise sequence processing to the noise channel. OP updated with ggsound_distro.zip.

These recent updates to duty cycle processing got me wondering about how people commonly use duty cycle envelopes out there. My approach has been that for the most part, I'm not using loops in duty cycles. I usually just set it and forget it. I do not use loop points in my FT files. So in GGSound's code, it preserves the last written duty cycle (or noise bit) every frame. So if you have a duty envelope which is just 1 frame long and stops and does not loop, you're going to continue to hear that setting as though it were looping. However, now that looping is supported, you can also set an arbitrary loop point somewhere in the cycle and it will loop over those values. I think this is how most people would expect duty cycles to work. Or would you expect to be forced to always specify a loop point if you want to keep that setting as a note plays? I'd be interested in feedback on this because I've been thinking about the feature in a vaccuum based on how I've been using it, myself.

The Skate or Die 2 title music has what sounds like looped duty cycles.

My hi-hats usually alternate normal noise ($03) and looped noise ($83) frame by frame. But they're usually fairly short anyway, and besides, Pently bakes noise period and noise quality into one byte written to $400E. For pulse instruments, duty is baked into the volume envelope.

Duty sequences are very good for creating an attack portion to the sound. 1 or 2 frames of different duty at the start of a note might be good for a guitar pluck, or a piano "ping". You can get a nice ring to the start of a hi-hat sound by using looped noise in a similar way.

Looped duty is less common but still has its uses. For example, it might approximate a raunchy saxophpone.

Sort of a combination of both, a volume that falls off combined with a looped duty that has an attack can make an "automatic echo" kind of sound, where having that attack frame repeat at lower volumes.


Sorry to be using only my own stuff as examples, but we're getting into territory where I can't think of examples from the commercial NES library so easily. I can see why shiru chose not to implement duty envelopes in famitone, since they're not quite so obviously useful, but I think they have a lot of utility.

I would just want the loop thing to work in the way that I simply export to text, text to asm and compile and have it work. I don't know what the question asks, really.

Hi,

First of all, hello everyone. Long story short, I'm currently writing music for a project in which I need to follow ggsounds limitations. I am not particularly knowledgeable about the technical side of nes programming, and I was wondering if someone here could help me determine why my project won't output correctly.

This is a single pattern. I can't figure out why I'm getting the "music.asm (184) : Incomplete expression" and "music.asm(193) : Can't determine adress" error when I try to output it with ggsound assembly test. The module was written in with the last version of famitracker (0.4.6).

I think I've respected the limitation of ggsounds and I'm trying yo determine if the error comes from my famitracker module or from something else. Any help would be appreciated.

I figured out the issue with this one. It's pretty small and wouldn't actually be visible from just the Famitracker file.

It had to do with the linker which references the files containing song data as well as the one containing GGsound constants. It had the include for the DPCM file commented out, and the test song contains DPCM. So it's referencing a location that isn't there.

To fix it, all you'd need to do is open the "linker.asm" file and remove the semicolon before the line including dpcm.asm. My apologies if I was confusing in my initial explanation.

I think what you ran into is that if you don't have any sfx, sfx_list won't be output and the demo program references the sfx_list symbol. If you don't have any sfx you can just let ggsound point to a bogus sfx list, and then never use any sfx and all will be well.

I noticed your loop doesn't sound quite right (edit: it seems your DPCM stream does not get exported) when it plays back in ggsound (nice loop, btw, I was mesmerized by it listening to it in FT for a few seconds). I'm going to try to figure out why and then update the distro.

Velathnos 2.0: DPCM is not exporting for you. Your DPCM instrument needs to specify a volume envelope even though DPCM does not use it. This is just a quirk of the converter and how it determines if an entire stream is silent. Easy workaround.

I noticed that ggsound produces a strange bend in your triangle instrument, too, which also seems wrong as I do not hear this in FT. I'll investigate this as well, next.

Thanks!

All right, thanks for looking into it!

Thanks Velathnos 2.0 and darryl.revok, you helped me find a bunch of stuff to fix!

OP ggsound_distro.zip updated with the following fixes:

-Fixed bug in converter so that all envelopes revert
to default for instruments that do not specify them.
-Fixed how beginning of note is detected.
-Fixed arpeggio processing to work with new beginning
of note code.
-Fixed bug in converter which was processing spaces in
track and dpcm names incorrectly.
-Convert spaces to underscores in output asm for
readability.

Velathnos 2.0 your song should now export and work perfectly except for needing to specify the (unused/bogus) volume envelope in the DPCM instrument. I put a note in the README about needing to do this. And of course also being aware that if you do not have any sfx, the demo program will still be looking for the sfx list so you'll have to remove that.

Thanks for the update, it's effectively working. Glad to have helped fix some stuff!

That being said, I have questions concerning the implementation of sound effects (sorry if it's explained somewhere, I've searched but haven't found the answers I'm searching for). So sound effects should be in the same famitracker file containing the music, with the "sfx_" prefix. What channels can be used for those effects? Also, should the effects be looped, like should I end them with the bxx effect? Thanks!

You can use up to 2 of the 5 channels for sound effects. You don't need to loop them. Also it is strongly recommended not to use looped envelopes or the Bxx effect for sfx, as the behavior may be undefined. I'll try to update the README to better explain how sound effects work. Basically they are processed to terminate after the longest envelope ends (after the last note). So if you use a looped envelope it'll only play that loop once for your sound effect. Also sound effects are not affected by tempo, they are assumed to primarily rely on envelope playback. Notes are played once on every frame (basically fastest possible update). So, they may sound slightly different on NTSC vs PAL, unlike music where tempo adjustments are made. Pitch adjustments in theory should be working the same way for both music and sfx.