Pently: a flexible, space-efficient NES music player

[thefox]

It's tough. With Musetracker playback engine I kind of wanted to throw everything and the kitchen sink in, which resulted in a reasonably performant but not-so-space-efficient engine (and only a few productions ever used it, although I think this was more because people were more used to the FamiTracker UI). In a perfect world the engine would support "everything", but the user would only pay for the features they actually use. But then it becomes quite difficult to design the engine, you'd need some conditional compilation at the very least.

And all this in order to get some users for your library, while getting not much more than a pat on the back in return. It really is a thankless job.

[tepples]

You mean like the PENTLY_USE_* flags I have? But seriously, I have no idea about what people want in DPCM in music in games because I don't myself use DPCM in music in games. I guess not everybody looks up to Tim Follin the way I do.

[tepples]

The top four reasons not to use Pently, even at the expense of having an overall shorter soundtrack for a given ROM size:

1. DPCM
2. Preferring to compose with linear pitch turned off, and wanting vibrato rate/depth and portamento rate to match FamiTracker exactly
3. Becoming frustrated with playback differences and not knowing how to ask for help
4. (Added 08-28) Using a third-party game engine with built-in FamiTone2/4 or GGSound integration but no Pently integration yet

In theory, a converter could compensate for #2 by using smaller vibrato depths and portamento rates for pitches below A-2 and larger ones for pitches above A-2, converting them from units of reciprocal frequency to log frequency. But in practice, it'd have to be a command line option, as 0CC-FamiTracker's text export does not include whether linear pitch was used. I reported this eight months ago.

This still leaves design of DPCM instrument data structures and composer support. Does anybody have test case FTMs/0CCs showing "typical" use of DPCM in a game soundtrack, as opposed to the data-heavy "Sunsoft bass" tracks I commonly see in FamiTracker Discord where people think nothing of using 64K for a 1-song NSF? And how could I encourage composers to keep me in the loop about problems they encounter?


EDIT (Tue 08-28): Add third-party game engine as the fourth reason

[FrankenGraphics]

How many samples are in the soundtrack of your game? More than 25? More than 63? More than 127? And how much space do they total? More than 8K? How many of them are played at different frequencies, vs. played at only one frequency?

Counterquestion: Does the definition of soundtrack include samples that are used mainly/only for sfx here?

Personally i feel more than 8k is greedy. Since you need your samples visible at all times while they're used, i'd try to aim for max 1k or maybe max 2k if it is something special. I'm not every composer though.

Playing at different frequencies is important if you want to conserve space. I feel it is important.
Even drums benefit from being played at different frequencies.

One limitation that both FamiTone and GGsound puts on DPCM is.. well it's two different takes.
GGsound - only one instrument can be a dpcm instrument in addition to its non-dpcm duty (iirc)
FamiTone2 - only instrument 00 can be a dpcm instrument in addition to its non-dpcm duty.

[tepples]

Counterquestion: Does the definition of soundtrack include samples that are used mainly/only for sfx here?

Yes. Pently in fact builds its current triangle+noise drums on top of sound effects. I'll also need to come up with a policy for what interrupts what, and it appears a bit more complex than the "whatever's louder" policy that other channels use.

Playing at different frequencies is important if you want to conserve space. I feel it is important.
Even drums benefit from being played at different frequencies.

Part of it is planning an efficient representation in sequence data, particularly whether I need to plan for every sample being played at every pitch.

[FrankenGraphics]

One thing i've wanted to try at some point but don't think i've seen (maybe because FT supports a whopping 256k of sample data, so few might've thought about it) is to use dpcm samples just for quick attack portions in tandem with a square or triangle that takes up the flag of the note where the attack portion ends. The attack portion either needs to go from its complex timbre to a tri/square one, or fade out while the tri/square fades in. Either way it could fit a limited size driver. Sometimes limitations may inspire new(?) styles.

Yes.

Then definitely at least "more than 25", i think. 63 sounds like a nice max but again, i wouldn't know the needs of other composers.

I'll also need to come up with a policy for what interrupts what

Maybe the sorting order of the samples could be enough to decide priority? It's not perfect but allows for some user agency at build time.

Part of it is planning an efficient representation in sequence data, particularly whether I need to plan for every sample being played at every pitch.

My experience is a bit too limited to be making a reliable verdict, but i've found the brightest few frequency settings to be the least useful overall so far.
For nonlooping one-shots, you typically get very short sounds for your sample length, and for "faux waveforms", you get very bright/out of tune sounds.

[tepples]

I have tried to keep Pently's data formats the same from version to version. The only breaking change I can remember is from Pently 3 (Thwaite; Zap Ruder; Double Action Blaster Guys; Sliding Blaster) to Pently 4 (RHDE: Furniture Fight), where I enlarged each instrument from 4 bytes to 5 in order to accommodate attack envelopes. So if you're converting a soundtrack from Pently 3 or earlier, keep this in mind.

[darkhog]

I think you could sacrifice some songs to make possible to add more sound effects. I can't imagine any game using 128 songs while I can imagine a game using more than 64 sound effects.

[tepples]

I could expand sound effects and instruments to 255, but that'd require a breaking change to their data format, namely converting them to striped tables. I'd prefer to get anything that doesn't require a breaking change done first so I can finish the Pently 5 series before branching off 6.

Issue #33 filed

[darkhog]

I see. Well, I hope it can be done eventually. As of instrument limit, it's pretty tight too. Can anything be done about it?

[tepples]

0.05wip10 (2018-10-28)

Driver

• Grace note durations no longer reduced by 1 frame
• Always write period high byte for triangle, fixing problem with zero volume in instruments (#32, reported by NovaSquirrel)
• Suppress linker warnings for export/import address size mismatch
• Overhaul names and scope of internal subroutines
• Rearrange conductor processing based on bytecode order
• Move sustain phase processing above pitch effects
• Remove redundant checks for attack injection in pitch effects
• Fix misbehavior when music and a slowed-down sound effect are played at once
• C bindings for commonly used functions (requested by adrian09_01)
• pentlyseq.inc: don't truncate patdef at 7 bits (reported and fixed by NovaSquirrel)
• mkrammap.py: rename to pentlybss.py to encourage remembering to include it when vendoring Pently

pentlyas.py

• A score can include other files, such as an instrument set (#29)
• o0 through o7 to set reference pitch (requested by zzo38)
• Allow grace notes in drum patterns
• Playing a pattern with only rests or waits is nonfatal
• Fix warnings for missing "fine" or "dal segno"
• Order of objects in the output is explicit, the same order in which they appear in the score (requested by NovaSquirrel)
• Error if no songs are defined (reported by NovaSquirrel)
• -A means --period-tuning; --output means -o

Packaging and demo

• Profiler: don't overreport CPU use if the shell has a lag frame
• Document how to skip the makefile's default autoplay (#30)
• makefile: Allow building from an arbitrarily named score by giving the name of the corresponding .nes or .nsf
• Add pseudocode to aid in porting to non-6502 platforms
• Add Travis CI build script
• Sample songs: Include the soundtrack of all games by Damian Yerrick that have appeared in Action 53. These are Concentration Room, Thwaite, Zap Ruder, and RHDE: Furniture Fight.

The "Isometry" track from the demo hits peak CPU usage of over 3800 cycles on a frame with a dal segno and play or stop commands on all five tracks. This may dissuade some users. Is there a need for evening out the CPU usage? And if so, is there a good way to go about this? Because if I can't think of something, I'll end up releasing what I have as the final version of Pently 5.

[tepples]

NSFe support has begun. Proper support for some chunks (auth, tlbl, taut, psfx, time, fade) will require changes to pentlyas that will benefit the ROM version as well.

Related issues:

• Move title and author to the score (#38)
• Write NSFe format (#39)
• Calculate track durations (#40)
• Write NSFe chunks to NSF2 (#41)

[tepples]

I'm not going to cover this up. I fixed a 3-year-old bug that jroatch reported before his username here was jroatch. This and other recent fixes look like enough stuff to push out another tagged release this week.

Now I'd like to know what's most important to users:

A. More than 51 instruments and 64 sound effects (with drum components included in sound effects)
B. More than 25 drums
C. ASM6 compatibility

[bazza]

C. ASM6 compatibility

As I compile it with asm6?

[tepples]

0.05wip11 fixes a few of the most long-standing issues and adds NSFe metadata support.

Driver

• Attack track allows grace notes (#35, reported by retrodpc)
• Channel volume in attack track is ignored rather than clobbering another variable (#35, reported by retrodpc)
• Option to round row grid to nearest tick on loop, pattern start, or beat (#37)
• Remove use of other .proc's labels in preparation for ASM6 port

pentlyas.py

• Fix bugs in fallthrough command and document it (#1, reported by jroatch)
• Specify tempo based on a musical duration other than a beat (#34)
• Calculate duration of each song and sound effect (#40)

Packaging and demo

• NES shell: Take track titles from score (#38)
• NSF shell: Take NSF title, author, and copyright from score (#38)
• NSF shell: Write NSFe and NSF2 formats (#39, #41)
• sfxed: Fix display of rate in slow (rate 10+) effects
• Move .pently files to audio folder
• Document workarounds for lack of reentrancy (#2)
• makefile: Add a recipe to convert a FamiTracker module with ft2pently (#36)

Download: ROM and source zip (below) or GitHub release