-
Notifications
You must be signed in to change notification settings - Fork 254
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
Messed up sawtooth channel in Descent game08.mid #705
Comments
Can you point to a particular time signature in the record where you think there is a problem? Also, is the Roland SC GM soundfont available somewhere? Otherwise it will be difficult to properly look into this. And you say bassmidi plays it correctly... can you supply an audio recording of bassmidi as well? |
It's a feature, not a bug. Your MIDI file enables portamento on channel 4 and sets MSB portamento time (CC5) to 8. In fluidsynth, portamento time is 14 bits wide with a resolution of 1ms. I.e. If other synths don't show this behaviour, they either do not support portamento, or they treat the portamento time as 7 bit value, in which case the portamento time might be too short to hear. Test it in the fluidsynth shell by specifying a different portamento time after the sawtooth started playing:
|
Nice tune btw. |
Right, and this could be more evident to listen by putting channel 4 |
Very interesting. So it's just that the MIDI file is essentially an artifact of its time and environment and the SC 55 hardware from 1991 is just less numerically precise than a modern software synth (and apparently bassmidi is as well). Thanks for looking into it in detail and so quickly.
Yes, the rest of the soundtrack has quite a few nice ones as well:
The Roland SC soundfont I used is available here: It's essentially the GM instrument set licensed from Roland and shipped with Windows since 1996. Given all the cobbled together Roland SC55 recreation attempts you can find on the internet I was really surprised to find that out. The only downside is that it's only sampled at 22khz. (Roland offers a SC55/88 VST that apparently has better quality samples, but as far as I can tell no-one has put in the work to rip them yet.) |
In fact the true reason is that for CC portamento time, MIDI specifications never specify the time resolution. That means that using different synths could lead to different results. |
I just fixed four zero-length notes on channels 8 and 10 (those with the "Oooh-Voice" instruments) by using a hex editor (the least destructive form of MIDI editing ;) ) |
@fgoepel @derselbst Someone has reported the exact same issue to us a few days ago: It took me a while until I realised this is portamento related 😅 Aren't you guys planning to add a configurable portamento range at the API level? As @jjceresa has pointed out, the MIDI specs don't specify the portamento range so it's up to the individual MIDI modules to come up with a range. Some softsynths allow setting the portamento range in their UI, Z3TA+ being one of them. If FluidSynth aims to be a generally useful SoundFount player, I think it would be best if the portamento range was fully configurable. Then I could just configure the Roland SC-55 range in DOSBox after init. Otherwise, I'll need to map the CC values themselves before sending them to FluidSynth, which is certainly doable, but it's a less elegant solution and it involves special-casing our FluidSynth path. Moreover, all such emulators that aim to emulate 90s-era Roland or GS-compatible MIDI gear would need to add a similar mapping formula, which is less than ideal and can create discrepancies between the different implementations. |
Are you suggesting to make the value range of "portamento time" configurable, while keeping the resolution of 14 bit for the portamento CCs? Or do you want to switch between 7bit and 14 bit resolution? And would this be a MIDI-channel-specific setting or a global setting for a particular
What range does it use and where is that documented? |
Thank you for your quick reply @derselbst. I did not want to waste your time so I've done my homework and have reverse engineered the SC-55 portamento behaviour to some extent. The TL;DR is the SC-55 portamento behaviour cannot be emulated on FluidSynth, so it's best to just filter out all portamento CC messages as that's the lesser of the two evils. Portamento is rarely used in DOS-era game soundtracks anyway, so it's no great loss. Details, if you're interested: (And no, the exact range and curve is not documented anywhere, plus it appears to be dynamically calculated based on the note-distances. It's a Roland trade secret or something 😎 ) |
Alright, thanks for the context. The exponential curve you've posted in the linked issue reminds me of the convex transfer function of soundfont modulators. For anybody else interested, a possible implementation of making portamento time configurable in fluidsynth might look like this: One could add a custom destination generator, similar as we've already done it for those three here: fluidsynth/include/fluidsynth/gen.h Lines 119 to 122 in 5a12a58
Then, a user could use Fluidsynth's internal logic of how to calculate portamento time would need to be adjusted to use the modulator logic, rather than using the current hard-coded linear mapping. Additionally, the calculation for this special generator should retain its 14 bit resolution (if possible - currently, all modulators are 7bit only). The drawback of this approach would be that we cannot account for any "dynamic-note-distance-weighting" during the modulator-amount-calculation logic, because we don't have information of destination- and from-key at that stage. Edit: Or you have a look whether this fork provides a better solution: mikelow@9f732c7 In any case, pls. open a new ticket or PR. |
FluidSynth version
FluidSynth runtime version 2.1.5
FluidSynth executable version 2.1.5
Sample type=double
Describe the bug
While playing around with fluidsynth, various sound fonts and game soundtracks I happened to notice this case, which is game08.mid from Descent 1. Specifically it appears that fluidsynth mishandles the sawtooth in channel 4 in some way. While it sounds quite gnarly, it's obviously incorrect when compared with a recording made on actual Roland hardware.
Under the link below you'll find a zip file containing the MIDI file, a recording I made using fluidsynth and the Roland SC GM sound font, and a recording by someone else from real SC55 hardware. It doesn't appear to be a faulty MIDI file either as playing it through bassmidi exhibits the same behavior as the hardware recording.
https://mega.nz/file/g3AWyboJ#vlAQSz_1AZ_6BDuY5i9K1RonGNp8ArLONo-zVXlNfxM
Let me know if you need anything else to reproduce this.
The text was updated successfully, but these errors were encountered: