search

ValleyBell / libvgm

A more modular rewrite of most components from VGMPlay. will include sub-libraries for audio output, sound emulation and VGM playback
irc://irc.digibase.ca/#vgmrips
136 stars 33 forks source link

Readme and general questions #79

Open mmontag opened 2 years ago

mmontag commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

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 commented 2 years ago

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

mmontag commented 7 months ago

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 commented 4 months ago

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