libOPNMIDI
libOPNMIDI copied to clipboard
Wohlstand
Glitchy playback/note cutting problem
There is one .mid song that has some weird problem at one point: https://instaud.io/3hkN - at 0:15 - 0:27 you can hear an arpeggio, meaning there are no free channels. Recording was made with eight Neko Project 2 cores and that should be enough to avoid note exhaustion? Rising the chip count to very high number like 16 or 20 helps a bit (still drums are dying for a second or two) The same problem appears on libADLMIDI, maybe it's slightly less severe. wtf.zip - .zip containing some recordings and a song in question.
Having tried in this configuration, I was able to confirm the problem.
- 8 cores ; same whether it was Neko or MAME
- bank YM2612.wopn from papiezak/DMXOPN2
This command reproduced the problem ./build/opnmidiplay [--emu-np2] YM2612.wopn Ring.mid.
However, this never occurred to me in a realtime playback setting.
Can this have some relation with the sequencer?
However, this never occurred to me in a realtime playback setting.
I'm not sure what do you exactly mean, but in VLC plugin, this song also sounds broken, and it's a real-time application that doesn't rely on sequencer I think...
At first I thought it may be some NRPN related crap, but then, it can be "fixed" by increasing chips count..
I created a report of arpeggios in this case. https://git.io/fhQ3Y As seen from this data, a majority of channels are occupied by notes with play under controller 64 Hold Pedal.
one more .mid file - in this case you can hear that something "holds" notes - alice_in_wonderland.zip
majority of channels are occupied by notes with play under controller 64 Hold Pedal.
The simplest solution would be to compute count of channels based on chip count and ignore CC64 Hold events when all channels are busy
For now, I don't get any farther that an assertion error raised, trying to change the goodness formula to ignore held status.
As the function updateArpeggio searches an active note to retrigger it, the note doesn't exist, and crashed at this point.
@Wohlstand There is trouble on a mix of held/non-held notes.
This is a log of before and after keying-off the note 63 on Midi Channel 0. https://gist.github.com/jpcima/ae0672394383627850a40ec4c5902aca
(mm:nn) is Midi channel and Note notation. S meaning sustained.
As seen, there is an accumulation of same (00:63) notes across chip channels. Not all are sustained.
After a key-off, there remains a set of users hanging around which are non-sustained are don't have an activenote on record. It will blow-up when arpeggioUpdate is called on these channels.