Some notes can be cut even if there are many, many channels available

[sneakernets]

This one affects "They're Going To Get You" from Doom. The high-pitched drone string "cuts out" even if there are ample channels available. In addition to that, the pizzicato strings "pop" as soon as the drone string is silenced. Very weird.

I have supplied a 25 second OGG of this happening. Sorry for this being loud, but I amp'd it up so you can hear. Happens between 20-21 seconds into the recording. increasing the number of chips to an obscene number "fixes" it, but it makes my recording software lag something fierce, so that's probably not a good remedy for it. getyou.zip

[Wohlstand]

I think, I'll need to make the monitor of busyness of channels to look how many channels are busy in a real. And yeah, for a long notes (are don't stopping while key is held), I must make the protection from a kill and kill channels are already released... Just now I have downloaded your fresh version of the bank, and the problem has been reproduced. I have planed same song on my 4-op bank and the tremolo strings was killed on 40'th second that is a max time value inside of measurer... So, I have got an idea - i'll add the "long note" flag to let channel manager to don't kill note while it is pressed. The algorithm of ADLMIDI's channel management is designed to don't kill any notes, but turn chords into arpeggio on channels overflow.

Also, please try with latest version (I did the test on old one that is in my PGE MusPlay built now), as I have recently fixed a crap against calculation of necessary 4-op channels: it checks the complete bank for count of instruments are using real 4-op mode, and if no 4-op instruments, it makes full range to 2-op. Because of inaccuracy, there are was 4-op channels dedicated that caused a false 2-op channels overflow when it must don't happen. I have fixed that.

[freq-mod]

I also spotted note cutting bug, however much more extreme than that: note cut.zip - flute section is almost mute, compared to recording of what should it be. Midi file included. Every bank affected, no matter whether 2-op or 4-op, both OPL3 and OPN2.

EDIT: might be due to unimplemented GS sysex calls (yet another SC-88Pro midi)

[jpcima]

I think I have also encountered the kind of problem described, and also another thing has caught my attention while working on dynamic banks: The code which determines the number of 4-op channels did not disregard the empty instruments in dynamic banks when it computed the count, which I also presume to be a mistake.

[Wohlstand]

With this: https://github.com/Wohlstand/OPL3BankEditor/pull/71 and with this https://github.com/Wohlstand/libADLMIDI/commit/70c83caace9911dc5d8b80c1653c96b073f88e4a the issue is no more reproducing on your bank even with 4 chips! :fox_face: :+1: Tremolo-strings still persistent and no more dying! I still to do some works until I'll apply it to everywhere...

[Wohlstand]

getyou-fixed.zip

[freq-mod]

yeah, looks like fixed now. midi that I linked few comments above still sounds broken, but it's most likely not connected to this issue; frankly speaking I have no bloody idea why it's that.

[Wohlstand]

As it's measurer problem in most, you need to download super-fresh version and run the full re-calculation to have that fixed. Embedded banks are NOT fixed yet as I wasn't ported fresh measurer into GenAdldata yet.

[freq-mod]

It's not about embedded banks. I tested this damn thing on customs only. But I will try to recalculate it one more time

[Wohlstand]

About of the "n_toh03.mid", I have checked it's internals and I see the piccolo part (not a flute, but in it's same family) looks weird (it does usage of two tracks):, and seems note-on/note-offs are conflicting here... Even I have the code that does ordering of note on/offs to prevent note on goes before note off of previous note

[Wohlstand]

Anyway, the reason of a crap in a piccolo is because of weird events in begin of the begin: (when I'll remove all of them except of "known", crap is going away): crapicolo.ogg.zip

[freq-mod]

That are japanese GS midis for you - always so hacky :anger:

[Wohlstand]

n_toh03_xg.mid.zip This is modded by me where I changed percussions into XG style and removed junky NRPNs are causing crap. I'll try to analyze the reason of the crap that came from NRPN events... Sometimes I think that GS synthesizers are becoming very weird in dependence from a model...

[freq-mod]

Sometimes I think that GS synthesizers are becoming very weird in dependence from a model...

OMFG they really are. Especially Roland SC88-Pro and SC-8850. These two are hybrid GS/XG and GS/GM2 synth respectively. For some reasons they became somewhat popular in late 90's despite being barely compatible with older synths (SC-8850 was notorious for this)

MIDI made to be played using these two break ADL(OPN)MIDI in crapton of ways

p.s thanks for fixed .mid

[Wohlstand]

Okay, the work against channel management and measurer has been completed! Tremolo strings now surviving even on single-chip with your DMXOPL3 bank! :smile: :fox_face: The only left the work against junk NRPN events are causing piccolo play junk

[jpcima]

The thing of NRPN is that they are manufacturer specific. So ADLMIDI probably tries to interpret messages intended for a different synth.

I would seem Joel has implemented these 3:

• 0x0108 MSB : vibrato speed
• 0x0109 MSB : vibrato depth
• 0x010A MSB : vibrato delay (ms)

It's possible that this specification was invented and does not match anything existing. Does this specification of NRPN ring a bell to you?

[jpcima]

xgspec.pdf It's XG. Found on document page 13. Can the use of these events be done under condition of the previous message "XG system ON"?

[Wohlstand]

Can the use of these events be done under condition of the previous message "XG system ON"?

It's need to turn them off when receiving GX system ON or GM (1/2) system ON

[jpcima]

ADLMIDI can be set to use GM mode by default. Then, it will not conflict with such files which use the Roland specification.

It can have a state variable to designate the active mode which depends on sysex receiving: GM/XG/GS

[jpcima]

MIDI Implementation Chart

I checked the manual of Roland SC-88 Pro and found these same NRPN with same ids. This is the definition according to Roland.

[Wohlstand]

One thing on my VSC there are not working (working on YXG50). Anyway, it's now implemented support for SysEx events and some of them are handling for now, so, GS way (that requires SysEx) of percussions is works now. For temporary, I was set vibrato depth do not be controlled when GS mode is set. @papiezak , Please test out the current result :wink: Those damned NRPNs are must no more annoy this song.

[freq-mod]

Tested it and yeah, it's alright! Thanks a ton!

About NRPNs, I'm gonna wait until you do the same thing in libOPNMIDI because I'm curious whether sysex support will fix some bizarre bug that was present only on OPNMIDI and gave me tons of headache

[Wohlstand]

About of libOPNMIDI, I in work to backport everything that was made here on libADLMIDI :wink:

[Wohlstand]

@papiezak , everything just now ported to libOPNMIDI too! :fox_face: :+1: For now you can enjoy same MIDI support as here now :fox_face: :wink:

[Wohlstand]

I'll close this as the main trouble of this issue has completely resolved.