Previous Page | Next Page
- by dj4uk6cjm at 5:15 PM EDT on June 28, 2016
- Is there a real MusyX VST? Or an actual executable windows software that can open GC/WII isos, read midi's within them and map certain instrument samples to soundfonts and save it? Sigh...asking too much again but I want something like that.
edited 5:18 PM EDT June 28, 2016
- by punk7890-2 at 5:40 PM EDT on June 28, 2016
- @antidote Neat. I'll keep an eye out. Hopefully in the future he includes Sinc Interpolation or perhaps, Cubic for a re-sampling method as there is some aliasing on samples at the moment.
- by antidote at 12:15 AM EDT on June 29, 2016
- @dj4uk6cjm, yes there is a VST AND a windows executable that can open files from certain GC/Wii game (not ISOs, that's a bit more complicated), and exports them out.
However mapping "instruments" to soundfonts is a bit difficult due to how MusyX works: every instrument points to a SoundMacro, which is a turing complete mini state machine that affects the sample, these macros can't be converted to SoundFont easily, or at all in most cases.
EDIT:
We already handle SRC through a 3rd party library called soxr, and it has Sinc interpolation but it's still experimental, also simply interpolating the samples won't remove aliasing on low input rates.
EDIT2:
Jack's words on the subject:
that's only available through soxr when variable sample rate is disabled
in other words, not at all AX compliant
it's still in the "experimental" phase
and some of the source samples themselves have unavoidable aliasing at such low input rates
the variable resampler works similar to MSAA
a basic blend routine of time-resampled audio
the variable rate is important to mention
that's how pitch bend is able to function without far worse stream discontinuities
edited 12:23 AM EDT June 29, 2016
- by kode54 at 12:37 AM EDT on July 1, 2016
- I'm amazed you can get away with using soxr for real time resampling of synthesized data. It has an incredible latency window size, something on the order of 10k-12k input samples before it will start producing output.
I would suggest looking at the resampler.[ch] included with my modplay and playptmod repositories, as it may not be the nicest resampler or support the absolute highest quality, but it definitely supports low latency.
- by antidote at 5:32 PM EDT on July 2, 2016
- We've modified soxr to use SSE, so the latency is actually really low, but you do bring up a valid concern.
Amuse is more than capable of having well over 100 voices running at once (we've hit 200 on some songs with amuse not missing a beat), that's including soxr's resampling. Granted you'll never be able to play black midis using Amuse but that's pushing the spec well past it's limits to begin with.
Edit:
I've just been informed that we're using the variable-resampler, which doesn't use the FFT codepath, which is where the latency comes from. Also the reason we use soxr is that it matches the behavior of the DSP extremely well, so we benefit from using it.
Jack:
soxr's variable-resampler is different
it doesn't use the FFT code-path
that's where all the latency comes from
it actually works more like the SRC in the DSP
that's based on supersampling the data
which is what I meant by "similar to MSAA"
the main reason for that is FFTs require a sizable sample-block to function
the VR resampler works on 12 samples at a time
extremely low latency
but it doesn't have the curve-fitting prowess
i'm sure if we switched to the static resampler, it would become rather expensive
edited 5:40 PM EDT July 2, 2016
- by jackoalan at 6:02 PM EDT on July 2, 2016
- Just to elaborate on what Antidote said, we're using the API passing `SOXR_VR` to `soxr_quality_spec`
This code-path is completely different than the FFT-using one (vr32.c), and the most latency actually comes from the OS' audio-buffering system.
Based on my findings from integrating SSE, the vr32.c resampler uses a supersampling FIR filter. It has a window of 12 samples for upsampling and 20 samples for downsampling (3 or 5 SSE vectors respectively).
Here's the modified vr32.c with SSE if you're interested:
https://github.com/AxioDL/boo/blob/master/soxr/src/vr32s.c
- by kode54 at 6:23 PM EDT on July 2, 2016
- I must have found a really bad port of soxr, because that port, even in the SOX_VR mode, used a giant FIR filter bank, and multiple banks at that. It used one per octave of transition, plus one for the partial octave at the end. Maybe because I was using SOXR_VR|SOXR_HQ or whatever?
I'd love to see this soxr you have, since it would be useful for at least testing the output.
- by antidote at 6:36 PM EDT on July 2, 2016
- Yeah, it was likely either a bad port or a misunderstanding of the API usage, this is how boo utilizes soxr:
https://github.com/AxioDL/boo/blob/master/lib/audiodev/AudioVoice.cpp#L81
And this is an example that comes with it:
https://github.com/AxioDL/boo/blob/6cbd086204bbe0bce4ad21c179c3e4cf8ea717b8/soxr/examples/5-variable-rate.c#L38
- by jackoalan at 6:37 PM EDT on July 2, 2016
- Ah, your problem could be how you were setting up the API, those two SOXR_ enums aren't part of a bitfield according to the usage examples.
Our complete `soxr_create` flow looks like this on a per-voice basis:
https://github.com/AxioDL/boo/blob/d08f25abd3b1c5659df530b0ec557ac01537b8aa/lib/audiodev/AudioVoice.cpp#L87
The resampler instances are re-constructed whenever a voice loads a new sample with a potentially different source rate, or if the system rate changes (which could be triggered by plugging in headphones on Windows).
- by punk7890-2 at 9:23 PM EDT on July 2, 2016
- I found a few small problems when playing Star Wars Rogue Squadron songs in Amuse (N64). When playing song 91 with group 03, it seems the strings and snares have incorrect release time on them. It appears that this is the correct instrument group for the song.
Previous Page | Next Page
Go to Page 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Search this thread
Show all threads
Reply to this thread:
HCS Forum Index
Halley's Comet Software
forum source