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.
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:
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.
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.