Readme and general questions

[mmontag]

Hi, I am considering replacing large portions of Game Music Emu (@kode54 fork) with libvgm in my project, but I'm confused about a few things.

1. Can you add a README to the libvgm root? (I think that would answer most questions.)
2. What is the status of the project? i.e., stable or in early development?
3. Does libvgm expose a C or C++ interface?
4. I have my own file reader and audio output buffer (common use case). What libvgm header file should I start with?

[superctr]

I can at least answer questions 3 and 4.

3: the emu, audio and utils components use a C interface, while player is C++ 4: you'd probably just want emu (edit: and possibly player if you want to play back VGM files)

[mmontag]

Thanks. Yep, I want to play VGM data. What is emu by itself useful for?

What do you think of using C interface for the player as well?

As an aside, every "music player" library I have integrated so far with Emscripten (game music emu, libxmp, v2m, mdxmini, etc.) has been a C API. I was reading a bit and convinced myself that I prefer a C API.

The music player interface (in general) is simple enough that it doesn't seem to benefit much from a C++ API.

[superctr]

What is emu by itself useful for?

I can think of emulators, software synths for music sequencers, sound driver reimplementations, etc.

What do you think of using C interface for the player as well?

I was initially opposed to having player written in C++, but that was Valley Bell's decision to make.

[mmontag]

The C++ player implementation is great, but can we add a C API on top of it? might try this out myself.

Also, what is PlayerA? I see it doesn’t inherit from PlayerBase but the S98 and VGM do.

[Eoin-ONeill-Yokai]

I have a similar desire since I've been toying with writing a gstreamer plugin that uses libvgm instead of libgme.

My understanding was that a C api was planned later for this type of use case. Was this or is this still the plan long term?

[ValleyBell]

Yeah, sorry. There are a few things that are still on my TODO list, which are:

• split the "audio" part off into a separate library
• convert the "player" to pure C, or at least make a C interface
• do better names for the "player" classes
• finally write the README

Both changes will be API breaking, as I'd like to do both at once. Unfortunately I haven't been working a lot on libvgm recently and I'm also stuck at how I should rename the "audio" part.

EDIT: "PlayerBase" will be renamed to "BaseEngine" (or something similar), VGMPlayer -> VGMEngine, etc.
"PlayerA" is the "main player" class, in which you register multiple "engines" (DRO/S98/VGM) and which does volume control, loop counting and fading.

[mmontag]

Nice, thanks for the explanation. I should probably wait until the dust settles. Would be happy to help with some smaller tasks.

[mmontag]

I ended up writing my own C interface with voice names:

https://github.com/mmontag/chip-player-js/blob/master/libvgm/player/player_wrapper.cpp. (Code style may not be the best, any suggestions appreciated.)

[Eoin-ONeill-Yokai]

@mmontag That's neat. I didn't have any luck on the gstreamer end of things myself.