Jump to content

MIDI stutter on track start and when looping (on hardware module)


de_doomy

Recommended Posts

Hey there, long time lurker, first time poster...

 

I've recently acquired an SC-88VL (which has been sounding phenomenal for the record), but I've noticed a timing issue where at the start of tracks, there will be a slight stutter/hiccup that leads to the first notes rushing before the rest of the track plays normally. I've recorded a sample below, where it is noticeable more on both E2M1 and E3M1. It will also continue to occur again once the track loops back to the beginning. I've tried in both source ports that allow you to select the MIDI device directly (GZDoom) as well as other ports (Cripsy, Woof) where you'd need to use Coolsoft MIDI Mapper/VirtualMIDISynth to override the default Windows GM synth. 

 

https://whyp.it/tracks/44962/doom-midi-stutter?token=6eg3Y

 

I've tested it on both a Komplete Audio 6 interface as well as a Roland UM-ONE mk2, and I've only noticed this mostly in Doom, as well as Sekaiju (only once looping from the end, beginning of the tracks sound fine the first playthrough)

 

I know this isn't a support forum and might be stretching how related to Doom this is, but I can't find much discussion if any about this issue and I was just wondering if any of the other folks here who use hardware sound modules on modern systems (in my case, Windows 10), have noticed the same issue occur to them. It's the only thing that's preventing me from completely enjoying the hardware!

Share this post


Link to post

Does it occur in other games with midi OST, like Duke Nukem 3D or ROTT? Have you tried all the IWADS? What about sourceports like ZDoom or Zandronum or Skulltag?

I really can't help with anything else, sorry, but these just came to mind.

Share this post


Link to post

As far as I can tell it doesn't seem to occur in EDuke, though music in that game seems to start after a bit of silence after the level loads so not sure if that's what causes it to be fine, as opposed to Doom's immediate MIDI playing. Seems to work fine as well in System Shock Enhanced.

 

I did some more digging and ran it through an XP virtual machine (with drivers for the UM-ONE) using ZDoom and sure enough, it still stutters.

Edited by de_doomy
word

Share this post


Link to post

I don't have an answer or solution, but all my Roland hardware does the same thing to varying degrees and I always chalked it up to the speed that the hardware receives MIDI data. MIDI files usually have all the non-note data at the beginning of a file, all being read at the same time, and to me it seems like the hardware is just trying to read it all before moving on. I wouldn't say it never bothers me, especially when recording playback for other people, but usually I can get lucky with it looping or sometimes just record multiple takes and splice the good one into the full song. And when playing games, that hiccup at the beginning of songs has never bothered me, though I do notice it. I want to say that's just how Roland hardware behaves, but hopefully someone has a better explanation, or even a solution.

Share this post


Link to post

I've done even further investigation and have tested most of the ports I still have installed and have made some interesting discoveries...

 

I've found that some of the older versions of Crispy, Chocolate, Retro etc. can in fact playback the MIDIs without stuttering. My results below:

TrXnq4S.png

 

I don't think it has anything to do with my configs (though I'm not 100% sure on that), but I did run Crispy 5.11.1 with a clean default config and still sounded fine. I'm also unsure with that version of DSDA because it sounds like it stutters, but to a lesser extent than the others I tested. It seems like something has changed in the audio playback department between these versions to start causing these issues but I'd have no idea otherwise.

Share this post


Link to post

some midis are just a mess :)) it's kind of a good idea not to have a note command on the very first tick, get all the channels initialized and panned first. and i bet some soundfonts initialize slowly during this time
an individual fix is really no help if yr enduring a systemic error but you can open a midi file up in whichever sequencer you like and draw a blank pattern at the start of each channel which often fixes these things

Share this post


Link to post
On 9/28/2022 at 5:47 AM, mikeday said:

For Crispy I am guessing this might be caused by the changes in this commit. Tagging @ceski for comment.

 

Thanks for the heads up, I was able to reproduce this with real hardware. I have a solution but it'll take a while. Edit: There's more work to be done with this.

Edited by ceski

Share this post


Link to post
  • 1 month later...

I noticed the same issue on Windows 10 -> CoolSoft MIDIMapper -> UM-ONE mk2 -> SC-55 mk2 in latest versions of Chocolate and Crispy when a new track starts, looping seems to be fine. PrBoom+ with SDL set as the MIDI player has next to no stuttering, but the music sounds muffled, which is why I suppose PortMidi is recommended for hardware - that has stuttering on track start as well.

Share this post


Link to post

I got an SC-55 + UM-ONE a bit ago and can confirm the stutter is there. It's so brief that I don't mind it much, but were I to record from the SC-55, I'd go with what yakfak suggested and simply add some blank space at the start of the MIDI to let everything get ready before playback starts.

 

I know this is only topic-adjacent, but if Roland sold a new version of the SC-55 with native USB out, it would definitely sell. These days there'd be no excuse not to load a few different banks/soundfonts in there too.

Share this post


Link to post

Funnily enough, there were some early 2000s modules in the Sound Canvas family with SC-55 mapping that had USB outs, but I've never looked into whether or not people have managed to use them on modern Windows, and I also don't know how well their mapping is compared to actual SC-55 units.

 

I've also now posted the issue on the Chocolate Doom GitHub just to document it within the more appropriate channels. In the meantime the older versions of my ports will suffice!

Share this post


Link to post
  • 2 weeks later...
  • 4 weeks later...

Happy to report that this issue has now been fixed (credits to ceski) in some source ports as noted on the GitHub issue page. I've only tested so far in the GitHub builds of Chocolate Doom and Woof, but with my delay value set to 100 in the config I'm not hearing any noticeable stutter and music changes are near seamless too!

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...