darkhog said:
Vibrato can be worked around though
Yeah, for example you can edit that constant at build time, or you can hack pently to look for it in RAM instead and change it on the go manually, for example as part of or prior to song initialization*. Maybe you can even write an intercepting routine that takes a message meant for something else to change it on the fly within a song. But you can't work around it using pitch envelopes (like you can in FamiTone2 or whatever), because there are none. That also means no detune, and no subtle pitch fluctuations in attack and decay portions (if you want to synthesize reeds, flutes, recorders, trumpets, guitar plucks etc, those would've helped getting more life-like results). One final method, which doesn't require any programming skills, is depending on your song setting and allows you to achieve an alternate rate vibrato with the help of repeating portamento notes, at the cost rapidly increasing song file sizes if you use it too much.
Vibratoes is a quite small problem. Pently is preset at a pleasant-sounding pop vibrato speed that just works in a lot of cases. I'm only mentioning it because i had problems with it for a specific soundtrack that relies a lot on more versatile vibratoes.
*(Trivia that might be useful for someone: Super Mario Bros does something similar before playing a new song. It sets the DPCM delta counter to different values, which has the very quirky side effect of offsetting the master volume of the triangle and noise channels subtly. A somewhat quieter and/or wispier tri channel can be achieved this way. but each write causes a small, unpleasant pop sound, so it's a little inconvenient to use it acceptably in the middle of a song. Theoretically, a low noise master volume could potentially also mean smoother sounding noise drum envelopes and sfx, since each step then is closer together in volume and you rarely use the normal max volume anyway. I don't know of any historical game that has used this to actual benefit though, and the tri channel is already quiet as it is compared to the square channels unless you play in the bright octaves; where this trick can help softening what would otherwise be ear-piercing[).
And hey, since it seems to be recommended by the dev of GGSound himself, it has to be better.
I think Derek is being a bit modest here, while also being friendly and reminding that there are alternatives (for users who don't mind getting technical, i'll add).
I'll maintain that there is no universal case of better or worse. I've spent a lot of time comparing the facts because i've been prompted or taken it upon myself to write songs for each and every of the alternatives out there, except the relatively new dougeff fork and some obscure old ones. If i'm to sum it up, here,'s a guide.
-Do you want as much cpu cycles as possible reserved for game logic? Or do you plan on doing sprite0 hit detection-based scroll splits, or just like the fact that no matter what you do, the driver will never cause CPU usage spikes? Do you have the space to store somewhat larger song files compared to FamiTone2? WIll you not need the DPCM channel? Then
Penguin is best (in fact, it is sometimes an effortless plug and play replacement for FT2). Note that sound effects are not as lean on storage as in FT2, but they don't add any extra work for the CPU, which is a plus.
-Do you want a super simple job composing, including chiptunes-grade music, don't care for technicalities, and using it for a game with modest resource demands? Then
famitracker driver (or rather
neslib+ft) is best.
-Do you want a well rounded, yet still quite lean driver? Then either
FamiTone2,
Pently or
GGsound is "best", a lot depending on the specifics of your particular game design, minute technical differences in what you actually can do sound design-wise/musically/conveniently, and also depending the composers' individual workflow/usecase**. Of the three,
pently differs most in its feature set, but all three also aim at balancing being between being lean and being versatile.
---Do you want an as straightforward as possible ft to practical driver conversion? I'd argue
FamiTone2 does the best job, closely followed by
GGsound, but it is splitting hairs. GGsound has better documentation, and also a video tutorial.
---Do you positively need a wider note range than C-1-D6? Go for either
GGsound or
Pently.
---Do you positively need a convenient way to change tempo in the middle of a song? then
FamiTone2 or
Pently.
---Do you plan on using DPCM? go for
GGsound or
FamiTone2.
---Do you positively need SFX on more than two channels? Rule out
GGsound.
---Do you plan on using Duty changes in an instrument?
GGsound is the most flexible, followed by
Pently.
FamiTone2 just can't unless you set the tempo to 1 step per tick, which is awkward.
---Is your sountrack very large? watch out for
pently's limitation of 51 instruments, 25 drum instruments and 255 patterns. Plan your patterns a bit carefully regarding pattern length and reusability.
Famitone might seem as limited, but in practice isn't because its limit is soft. It refers to how many songs and tracks you can pack per project file, not per driver instance. You can modify the driver to look for instrument/pattern data in swappable banks instead and interleave that data on those, but it doesn't come ready.
---Do you want to compose long, complex songs but still retain a tiny filesize for your songs, making the most out of Pently's dynamic approach? Then go for
pently.
---Do you need to be more CPU efficient than
FamiTone2 or
GGsound, but can accept being less CPU efficient than
Penguin? Go for
pently.
---If MML scripts doesn't hold you back, time-wise or creatively, Then
Pently is for you. If you prefer MML over tracking, then
Pently is definitely for you.
---If you want a simple to use vibrato and portamento as opposed to write these things into instrument sequences, then
Pently might be for you. But also - see below.
Lastly, a special mention:
-Are you looking for a conventient middle ground between the three above and
famitracker, wish
FamiTone2 had the full note range and a few potentially song file size saving composer conveniences added to
Famitone2, but don't care for PAL support? Then
dougeff:s FT2 fork is for you. But dropping PAL support should be a big nono for anyone who wants to sell physical copies of their game. For freeware ROM distribution, it's not too bad since most will just pop it in an NTSC-defaulted emulator anyway. Also be advised that you need to change it's RAM usage page manually to fit your game, since Doug used an absolute address @ $700. That needs to be changed by you.
Sometimes, the things you need for your soundtrack or game doesn't add up. Then there's only three ways to go:
-Simply accept some limitations or costs. NES development is all about accepting limitations and costly workarounds.
-Modify a preexisting driver, like dougeff or DRW have done, to your personal taste and needs.
-Or write a new one, which will likely take years, but on the birght side, it will enable even more nuances in the homebrew nes software catalog. And you're officially a hero.
**Anyone can take the time to build up skills using MML notation, but it is fundamentally a step backward compared to a realtime feedback sequencer or tracker. Each to their own, but personally i do not wish to go back to qbasic days of composing: write, build, run, repeat. It was fine for me when i was young and time felt infinite but It's just too slow a process for me nowadays. Mileage may vary. As for the "automated" famitracker to pently conversion, here's what the comparison wiki says:
"The native input format ("Pently score") is inspired by MML and intended to be familiar to users of PPMCK or LilyPond. Conversion from FT text export is through ft2pently by Joshua Hoffman. As Pently score was originally intended for human writability, some features don't map well onto FamiTracker features, requiring manual configuration of ft2pently or manual editing of the Pently score it produces".
and
"Automatic conversion doesn't use the newest features (linear portamento and 2-frame arpeggio) due to converter author's unfamiliarity with 0CC-FamiTracker."
In other words, you need to understand the structure of both formats, be prepared to do a lot of manual post-process tweaking, or even potentially be ready to modify a python program to suit your needs.
So basically, either way you go about it, you're looking at longer production time if you're going for similar results as you would have composing for another driver. For me, it may sometimes be worth it, but only on a case for case basis. As far as i'm concerned, It's not a general purpose upgrade for everyone. It's a tool for when its specific features are actually warranted in a way that another driver can't cover. A pently-based realtime editor would change all of that, which was why i wrote "would have been my 1# goto driver". But writing one such is a huge undertaking. That statement should btw have been written with the appendage "for technical reasons". If the reasons were purely musical, i don't think i'd never need to look further than varying between GGsound or Famitone2.
Even just looking at ROM, ZP, BBS figures for each driver, that is pretty treacherous. As a composer, you have a larger impact on the total filesize than what the bare ROM footprint of the driver has. The critical point to be on the lookout for is if your software is using a fixed bank and the audio driver is part of that bank. Then its ROM footprint can potentially be critical depending on what else you need to fit into the fixed bank. But... NESmaker is a package where you've got all that figured out for you, so what's left to look out for is just the song file sizes.
A big pro with the Pently toolchain is that it is very actively maintained. Last update was 2 days ago. I'd argue the same goes for GGsound. It has gotten a lot of attention from Derek since it was chosen as the standard driver of NESmaker (and for good reasons - it is very well rounded).
In summary, going through all the differences between GGsound, Famitone2, Dougeff:sFT2, neslib+FT, Penguin and Pently to determine what is best for your particular game is a lot of nerdy research, and requires a general idea about 6502 programming and python programming is also good to have a general concept of. The nesdev wiki summary on their differences is only scraping the surface and leaves some important factors out.
Reference:
https://wiki.nesdev.com/w/index.php/Audio_drivers