Multi-platform modular music creation studio
- Posts: 3
- Joined: Thu Aug 16, 2012 7:38 pm
- Location: Ufa, Russia
Ever since I've moved to Linux pretty much everywhere, including my laptop, it was a bit harsh on the battery life to use SunVox or Pixilang to listen to SV-tunes and albums.
So here goes: https://github.com/vladkorotnev/MPD
This fork can:
- Play SunVox files (only at 44100/16 for now, but still this helps save disk space by storing SunVox projects instead of WAV/FLAC files!)
- Read SunVox file title and duration
- (Somehow buggy) Seek forward and backward
However, I don't have that much knowledge in Linux build systems yet, so if this is really something someone would use, I am seeking help with the following:
- Writing the Autoconf files properly (in the commits you can see I went pretty hard on them and just unconditionally built the SunVox plugin in)
- Maybe it would be a good idea to make it use the dynamically linked SunVox library (via dlopen), but I couldn't get it to build, it would keep on telling me about unresolved references to sv_* functions. If it's possible, it would be good to place the path to the library into the decoder config section of mpd.conf.
- Once it's done the proper way, we could submit a pull request to the upstream MPD repository, and build packages for various distros.
- If it's accepted into the upstream, eventually there will be no need to build our own packages, but it will be necessary to package libsunvox.
So... anyway, it works!
- Posts: 207
- Joined: Tue May 10, 2016 9:51 pm
The more the SunVox library is used, the better, I say...
Some thoughts on seeking -- many SunVox projects depend on LFOs or tracker commands to modulate parameters... and the LFO cycles of those are often reset at the beginning of a song, or reset at specific points in the song.
By seeking to another point in the timeline, this could cause LFOs to go out of sync with their intended phase. Additionally, any controller values that were changed by tracker commands, that were bypassed via seeking, will not have been executed. This could mean, for example, that something that should be at a low volume in a song is still at high volume, because the lowering of a volume controller was skipped over and never executed.
To get truly accurate seeking, you should probably pre-render the entire song to an audio buffer (either in-memory or disk-cached) at full speed at the beginning of playback, play audio from that buffer instead of allowing SunVox to output sound directly, and restrict seeking to the parts of the song that have been already rendered. (Perhaps if seeking past the current end of the rendering buffer, it could just wait until the rendering caught up with the playback point, then start playing.)
This would be more work, yes, and maybe keeping the "buggy" seeking is easier for now... but nevertheless wanted to describe the two different options available and what's likely happening internally with your current seeking method.