A constant-cycle music engine

Discuss NSF files, FamiTracker, MML tools, or anything else related to NES music.

Moderator: Moderators

User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

A constant-cycle music engine

Post by pubby »

Over the weekend I wrote a music engine that runs in a constant number of cycles per frame. The intention was to have an engine that could be hidden in timing-critical code such as parallax effects, and also to avoid the dreaded lag spikes. Currently, the cycle count is 766, which makes it far faster than other open-source engines. For comparison, Famitone peaks at 3000+ cycles and GGSound peaks at 5000+. I think Pently peaks at 2500+, but I'm not sure.

The converter converts from Famitracker and supports instruments with Pitch/Volume/Arpeggio/Duty. Nothing else is supported; no effects nor volume columns. DMC is not supported, nor are sound effects or PAL pitches.

It uses 12 bytes of zeropage and $100-$156 in stack space. The converted songs are not as space efficient as other engines, but they're small enough for my purposes.

Anyway, you can find the code here: https://github.com/pubby/penguin Keep in mind this is not a library; I wrote the code for myself.

I'll attach a ROM that plays Ralph 4's music.
Attachments
penguin_demo.nes
(24.02 KiB) Downloaded 432 times
Last edited by pubby on Sun Sep 24, 2017 10:07 am, edited 1 time in total.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: A constant-cycle music engine

Post by tokumaru »

Cool, the idea of running the sound code at times you'd otherwise not do anything (e.g. while waiting for raster effects) is very interesting. And 766 cycles is pretty fast, about 7 scanlines only. Will take a better look at this when I get to my PC.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: A constant-cycle music engine

Post by Bregalad »

nor are sound effects or PAL pitches.
PAL pitches are usually as simple as adapting the pitch table to PAL values.

As for sound effects, the lack of them would really make your engine unsuitable for a game, although the concept of a constance-cycle music engine still apply.

Personally I was wondering how feasible was a fully constant-cycle game engine feasible. This could ease raster split a lot, perhaps impressive parallax scrolling could be done in-game without even needed neither sprite-zero hits nor IRQs.
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: A constant-cycle music engine

Post by Memblers »

Very cool, and very impressive too! Less than 7 scanlines of time, that fits well within a row of background tiles.
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: A constant-cycle music engine

Post by pubby »

Thanks.

The newest update adds sound effects and PAL pitches.

Sound effects were implemented as one-off instruments that play single notes. This makes them zero-cost; memory and cycles were not increased. PAL pitches on the other hand added 24 cycles and 2 bytes zeropage. The current cycle count is now 790 per frame.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: A constant-cycle music engine

Post by Bregalad »

pubby wrote:PAL pitches on the other hand added 24 cycles and 2 bytes zeropage. The current cycle count is now 790 per frame.
They should come at zero costs, really. All you need is to change the pitch table's values. Sound engines needs not supporting PAL or NTSC pitches at runtimes - they should just be configured at compile time to run either version.

Yes, technically you *could* have a runtime check and this comes with some advantages (only one version of the ROM), however that's not how it's typically done - most of the time you'd want to have one NTSC version and one PAL version of the ROM, and all the difference is made compile-time only.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: A constant-cycle music engine

Post by rainwarrior »

This is an interesting idea. Though it's not something I think I would ever want to do, it's always interesting to see a different approach to the problem. Thanks for sharing the source code.
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: A constant-cycle music engine

Post by pubby »

I finally got around to using this, and found a few bugs along the way. The repo has been updated.

I forgot to mention, but it does support the full range of pitches and duty cycles, which Famitone does not. The ROM usage is pretty bad though; about 2x that of Famitone. Maybe one day I'll optimize it better.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: A constant-cycle music engine

Post by FrankenGraphics »

this piece of BGM was written with the intention to comply with your driver, just thought i'd let you know. :) . Sadly, the mini game got shelved indefinitely as elseyf needed to tend to other things. It is meant to use the cycle constancy to reliably time a few scroll splits without irq support.
Last edited by FrankenGraphics on Sun Jan 28, 2018 1:32 pm, edited 1 time in total.
User avatar
GradualGames
Posts: 1106
Joined: Sun Nov 09, 2008 9:18 pm
Location: Pennsylvania, USA
Contact:

Re: A constant-cycle music engine

Post by GradualGames »

:shock: Well, this is humbling! By the time ggsound burns 760 cycles, it has just had its coffee and is still waking up in the morning. Ah, time to actually make sounds now! :lol: I can really learn something from this code. Thanks for sharing.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: A constant-cycle music engine

Post by tepples »

Feel free to mention anything pertinent in the engine's entry in the wiki's list of music engines.
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: A constant-cycle music engine

Post by pubby »

this piece of BGM was written with the intention to comply with your driver, just thought i'd let you know.
Cool! That sounds really, really good.
GradualGames wrote::shock: Well, this is humbling! By the time ggsound burns 760 cycles, it has just had its coffee and is still waking up in the morning. Ah, time to actually make sounds now! :lol: I can really learn something from this code. Thanks for sharing.
The biggest optimization comes from dividing the work out across multiple frames. I divided it into 4, and well, that's why it's 4x faster than famitone.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: A constant-cycle music engine

Post by tepples »

pubby wrote:The biggest optimization comes from dividing the work out across multiple frames. I divided it into 4, and well, that's why it's 4x faster than famitone.
I've considered doing some of that in my own engine, checking for loop commands during downtime on frames that are not the start of a row. But to compensate for the lack of Sxx and Gxx, someone might need to use speed 3 to get (say) thirty-second-note resolution at 150 BPM. How would an engine that splits work over four frames cope with speed 3?

Also throw std::runtime_error("pattern size not multiple of 8"); would blow up on the 36-row patterns of the 2 AM theme in the FamiTracker version of the Thwaite soundtrack, which is in 9/8 time.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: A constant-cycle music engine

Post by FrankenGraphics »

Division of workload across frames - that ought to be a good technique for any future driver aspiring to drive INL:s expansion audio project. More channels = more burden (and potentially more data, depending on how the extra channels are facilitated).
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: A constant-cycle music engine

Post by pubby »

If I ever rewrote it I would probably use 3 frame resolution instead of 4. I didn't know much about FT music back then and it turns out that 3 speed is common and useful.

You can sometimes fake faster speed with arpeggio sequences, but that's a pain.
Post Reply