-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
General idea and roadmap #20
Comments
The Mac version of
Does this mean |
Yes, that's correct. We have a Core Audio driver: https://github.com/ValleyBell/libvgm/blob/c068dffd272bc7ad3a8e96b17426b3f48e7ccf2d/audio/AudDrv_CoreAudio.c In the vgmplay config, setting |
Works like a charm. Can't wait to see what people make with this! |
Is it the correct place to add a feature request? I have a project were I'd like to feed vgmplay from a pipe. I know .vgm files have a header etc, but once the header has been read or the clocks correctly set, it could be useful to process incoming events in realtime. This could be useful to test sound engines or libraries against emulated chips. What do you think about it? |
Real time via pipe is not really feasible, anyway, since pipes buffer data at rates you don't really control, similar to how USB devices buffer commands in blocks. You'll likely want to handle timing and delay commands yourself as you stream them to it. Even if it's only stepping in small steps between commands and checks for input, assuming you're piping data from a MIDI or HID input. |
No, in general feature requests should be new issues.
This sounds interesting, but I won't add parsing custom commands for now. |
Okay, I didn't know about this library, but this is exactly what I needed. thanks a lot. |
General plan and current state
The idea behind libvgm is to make a collection of libraries and classes that make it easy to write a VGM player or programs that emulate sound chips in general. It includes sub-libraries for audio output, sound chip emulation and VGM playback. (and maybe VGM parsing as well)
The project is CMake based and will allow you to enable/disable almost all features. So if you include it within your project, you may e.g. just compile the sound chips you really need.
C++ might be used during development when I think that stuff is faster/easier to do with it. Eventually I'd like to have everything as pure C code. (mostly C90 with C++ comments)
audio library
The audio sub-library should be a simple abstraction layer in order to allow platform-independent audio output. There is support for multiple (often platform-dependent) "audio drivers".
You can either set a callback that will be called with a buffer to be filled or you can poll the driver and explicitly send data to it.
Features:
emulation library
The emulation sub-library allows you to emulate sound chips in software, resulting in samples being rendered into a buffer. In order to access sound chips, you need to read and write registers and memory. It focuses on being fast and flexible rather than being very easy to use.
player library
The player sub-library should make it easy to play back VGMs (and possibly other logged formats). It uses the emulation library for sound chip emulation and outputs samples into a buffer.
Future plans
audio library
I don't have any additional future plans for this right now. Maybe a dummy device that just redirects all data to custom callback? (for potential FLAC/MP3 export in host applications)
emulation library
player library
other
The text was updated successfully, but these errors were encountered: