ipatix commented 9 months ago

Overview

Since there are a couple of major things that I, and I believe also other, people would like to be implemented in agbplay I want to open this issue and collect things that I do plan to implement when I'm in the mood and I get some time again to work on agbplay.

Graphical User Interface (GUI)

agbplay's development was started in a time where I was getting a lot into the Linux world and applications. Thus agbplay has to some misfortune got the curses UI that we have today. While it does have the odd advantage on easily being usable remotely (which I have used before) I have to accept that this is really not a very useful trait. I know that there are some experiments with GUI support done here but I'd like to have the GUI somewhat be part of the main project.

This leads me to the plan of splitting the current program into 3 modules:

GUI
Headless program
libagbplay

If you have any suggestions what the GUI and the headless version should be able to do, please let me know and I'll add it to a list. Also any ideas regarding the library interface would be welcome.

Do we really need a UI that resembles classic Sappy (which agbplay was loosely based on)?

New features

Settings editor.

Currently settings have to be manually changed in the JSON. If you want to quickly change things that becomes rather cumbersome and I'd like this to be possible with the UI.

gsflib support

The current gsf support via the python script is somewhat hacky, as it merely creates a songlist. The original ROM is still required. Since from my understanding GSF strictly still is a ROM with everything but sound stripped, it should be possible to implement GSF support. This could vastly improve usability as people can just load one of the many tagged releases.

Perhaps this also depends on the game profile feature below since I don't want to implement GSF editing. Thus you'd have to choose between importing GSF tags or using an existing profile.

Multiple game profiles

With ROM hacks people will often use the same game identification for ROMs with different playlists, different samples or different sound driver configurations. I want a quick way to select which profile the current ROM uses to change all the settings which are currently bound to the 4 digit game IDs. Perhaps even automatic detection of the profiles via magic bytes in a ROM which the modder can place somewhere.

Sample and Voice Table overrides

Some people make enhanced versions of soundtracks and I'd come in handy to allow arbitrary instrument overrides to be defined. It should be flexible enough to for example allow a sample override for a specific song, Or like changing configuration values per song, per track, etc.

Emulator integration

So called "high level emulation" for audio on GBA has been discussed for some time now. NanoBoyAdvance and mGBA have an option for it, but for most of the time (in my opinion) they don't sound very good nor do they work reliably. If libagbplay provides an API that resembles the complete feature set of mp2k/m4a it'd be cool to expose them such that emulator developers just have to hook the right funtions and forward them to agbplay while the emulator will then receive an audio stream.

Improved error handling

Currently, agbplay will very almost always throw an exception if there is an error in the song data. The original code (of course) does not do this to avoid crashing the game. Unless a fatal error is occured, playback should continue with just a message in the debug log and the problematic sound being muted/skipped.

Tagged releases

Currently agbplay really doesn't have versioning except commits on the master branch. For users it may become difficult to track if anything has changed. So there should be version in a vA.B.C type of scheme and a changelog which at least briefly mentions which things have changed (e.g. sound generation, enhanced reverb algorithm added, bug fixes, etc.)

CMake build system

I know that some people will not like this but at some point I'd like to replace the (flawed) Makefile with a more high level build system like CMake. Simply to make dependy management easier and allow easier inclusion by other projects via submodule.

Binary releases

This somewhat goes in hand with getting rid of the terminal curses UI. This is what currently prevents agbplay from working reliably across platforms due to differences in Unicode support. Ideally I want users to just be able to download the program and run it.

You have ideas and suggestions?

So if you have made it until here: Do you have any suggestion that is outside of what I've mentioned here? Feel free to discuss and leave your comments.

kittertron commented 9 months ago

This is kind of niche, but a VGM logger for PSG. Since the GBA's PSG is basically just the DMG PSG, GBA psg data can be logged into VGM, even in MAME. The use-case of this is really specific, but it is something I'd like to see added!

ipatix commented 8 months ago

What do you mean with logger? A log file?

kittertron commented 8 months ago

What do you mean with logger? A log file?

I meant something that would be able to log a vgm file, which is a log of soundchip instructions that can be played back as audio, but now that I think about it I don't quite know if AGBPlay uses emulation for the PSG so I don't know if it'd be possible. Nevermind to that, sorry.

ipatix commented 8 months ago

I don't see much purpose for that. The PSGs on the GBA are not programmable via instructions. They only offer register reads and writes. In addition this would only give you playback for PSG and not PCM. I could probably be done to a certain extend, but I personally don't see much use for this.

scr-trees commented 6 months ago

Not sure how much work it would be, but it would be amazing to get DKC3's sound engine to output the crystal clear sound of AGBPlay. I'm not even sure what the issue is with that game. Either way, it's awesome that you're still working on this project.

ipatix commented 6 months ago

Not sure how much work it would be, but it would be amazing to get DKC3's sound engine to output the crystal clear sound of AGBPlay. I'm not even sure what the issue is with that game. Either way, it's awesome that you're still working on this project.

If it doesn't use Nintendo's sound driver MP2K, then I will not implement it.

ipatix commented 3 months ago

Just wanted to give a quick update on how things are currently going:

The barebones GUI now exists, but it still lacks a few features:

[x] file export
[x] about screen
[x] settings editor
[ ] profile editor
[x] show current sound mode
[ ] chord analyzer
[x] saving profile
[x] playlist editing
[x] logging
[x] gsf support
[x] graceful error handling (e.g. a failed song table scan currently crashes the program)

This does not yet include the new planned features such as:

[ ] sound overrides
[ ] emulator integration
[ ] headless mode (i.e. exporting from CLI)
[ ] zip'ped profiles

General bugs to fix:

[x] correctly handle varying buffer sizes of audio API in respect to agbplay's buffer size at lowest latency without lockups.
[x] fix unicode encoding of strings in profiles (we should probably use std::wstring internally for windows compatibility)

H-A-M-G-E-R commented 3 weeks ago

For emulator integration, let agbplay generate only the PCM samples and the emulator generate only the CGB channels.

ipatix commented 2 weeks ago

For emulator integration, let agbplay generate only the PCM samples and the emulator generate only the CGB channels.

Although I'd generally question this idea, implementing this would be non-trivial either way. This would require agbplay to stay perfectly in sync with the emulator. The emulator integration is currently planned by means of hooking all the MP2K library functions and discarding the original call. If the original call would be kept, this would certainly cause desync at some point, possibly for unpredictable reasons like game lag.

The only "proper" way of implementing support would be to hook on a channel level, but this is not really intended in the design of agbplay, since agbplay does not have things like a channel limit. Also sub 60 Hz timings would no longer be possible (which have been tightly integrated in agbplay since ever basically).

H-A-M-G-E-R commented 1 week ago

What if we do the reverse: emulate the song/sound in the emulator to find inconsistancies between agbplay and the emulated audio. I would also like agbplay to dump the songs, voice groups, and samples in ASM format so I can inject them to another rom using the sappy engine or to troubleshoot.

ipatix commented 1 week ago

What if we do the reverse: emulate the song/sound in the emulator to find inconsistancies between agbplay and the emulated audio.

This does not work be design, since there will be incosistencies, simply due to the quality improvements.

I would also like agbplay to dump the songs, voice groups, and samples in ASM format so I can inject them to another rom using the sappy engine or to troubleshoot.

I'd never say never, but I certainly won't implement this any time soon, since there already are tools that can do this. The people who do decomps frequently do this. I also have a program which does this (check m4a2s), but it is rather old and possibly has flaws which the decomp tools do not have.