MUSE (The Music Engine)

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
MUSE (The Music Engine)
by on (#83854)
I've released a new 6502 sound engine called MUSE. Here are some of the features:

- Note slides
- Volume slides
- Glissando
- Arpeggio
- Vibrato
- Tremolo
- Vibrato depth and note slide speeds are independent of the note frequency
- Note slides and arpeggio interact perfectly (you can have an instrument with an arpeggio envelope, and apply a note slide to it)
- Sweep trick for setting the hibyte of pulse period without resetting phase
- NTSC/PAL speed/frequency compensation
- Global volume setting for volume fades, can be set to affect both music and sound effects, or just music
- Sync events for synchronizing visuals to audio, among other things
- Pausing of music and sound effects individually

Download it from http://kkfos.aspekt.fi/projects/nes/muse/

You'll also need v1.4 or later of Pornotracker if you actually want to use this library (the library package is also included in the Pornotracker release).

by on (#83858)
Looks great to me.

by on (#83859)
Looks interesting, I guess I'll have to try this! The way you found to include this in a program is pretty interesting, because we get to choose where to place the code and the variables.

by on (#83860)
It is a good thing to have many ready-made sound solutions, although I suspect that most people will continue to reinvent the wheel and make their own players and tools anyway.

Since Pornotracker has FamiTone-compatible export, it would be interesting to compare player+data size and CPU load for Muse and FamiTone using the same simple song (with FamiTone limitations, because it is inferior).

by on (#83865)
Might be something worth looking at for a future project. The arpeggio is one thing that is missing from the engine I use.

Sounds like a good thing though.

by on (#83874)
I made a hacked version of Dragnsf2 with arpeggio support. Want it?

by on (#83883)
tokumaru wrote:
Looks interesting, I guess I'll have to try this! The way you found to include this in a program is pretty interesting, because we get to choose where to place the code and the variables.

Yep, it was bit of a coincidence. I noticed that CC65 can generate "o65" type output files, and then convert those to a statically linkable library using a tool called "co65". I opted for this because the original source is very heavy on macro and CA65-specific feature usage, so it'd be very hard to port to different assemblers directly (especially maintenance would become hell).

Shiru wrote:
It is a good thing to have many ready-made sound solutions, although I suspect that most people will continue to reinvent the wheel and make their own players and tools anyway.

Yep, that's the way it goes. It's hard to satisfy everybody's needs. Some want more features and are fine with a bigger player size, some want the player size to be as small as possible and are fine with more CPU usage.

Personally I'm looking to use this in a project where ROM size isn't a concern, so I set my goal to fit it in 8K (so it can be banked in). I haven't field tested it very much yet, so I don't know how well the song data size etc fair in comparison to other engines. I also plan to have WRAM so I may even add auto delay support some day...

BTW FamiTone was a major inspiration in doing this engine, so thanks for that!

Quote:
Since Pornotracker has FamiTone-compatible export, it would be interesting to compare player+data size and CPU load for Muse and FamiTone using the same simple song (with FamiTone limitations, because it is inferior).

Yeah this could be interesting. Although if I remember correctly the FamiTone export from PT doesn't optimize instrument envelope references properly, for example (it just writes them all out for every used instrument), so this could affect the results.

E: Forgot to answer to tokumaru.

by on (#83892)
Great job man and some clever coding there though at the same time I was disappointed to not be able to trawl through your player code.

;)

Edited to add: Auto-delay now too? :)

by on (#83961)
neilbaldwin wrote:
Great job man and some clever coding there though at the same time I was disappointed to not be able to trawl through your player code.

Yep I'll probably release the original source some day...

Quote:
Edited to add: Auto-delay now too? :)

Yeah it's implemented in the tracker but not in MUSE at least yet. It's a very nice feature (especially now that I consider volume envelopes ending in 0 as note offs), so thanks for inventing it. :)

by on (#83974)
The more the merrier. Good thing to see a new driver/editor combo.

nintendulor DX extensions, savetate for powerpak then this driver. Your on a roll these days :)

by on (#96850)
There's a new version (v03): http://kkfos.aspekt.fi/projects/nes/muse/

Nothing too drastic, I changed the "speed compensation" so that envelope and arpeggio updates are also skipped whenever a frame is skipped. Previously I thought running them at the system rate would be better, but I've changed my opinion on that. Main problem is the volume envelopes, the difference in speed really can be heard there.

I also added separate flags for speed compensation and note frequency compensation, so that it's possible to set just the note frequency compensation for Dendy.
Re: MUSE (The Music Engine)
by on (#98632)
It seems ca65 has a problem with one line being too long, and when I create asm-code with "musetracker -s ...." it creates one of those lines, so I have to manually edit the file each time I have made changes to a song or a sound effect.

Nothing huge but a little annoyance, and if it could be fixed that would be awesome! :)
Re: MUSE (The Music Engine)
by on (#98638)
jayminer wrote:
It seems ca65 has a problem with one line being too long, and when I create asm-code with "musetracker -s ...." it creates one of those lines, so I have to manually edit the file each time I have made changes to a song or a sound effect.

Nothing huge but a little annoyance, and if it could be fixed that would be awesome! :)

I'll add that to the TODO list but I can't promise to fix it any time soon. Anyway, I'd recommend using the latest snapshot version of CA65 which shouldn't have that problem.