Qmidiroute patched for some GS use

Chat about anything related to the QuestStudios Archive, Classic PC Games, MIDI, Etc.

Moderator: Quest Studios Archive moderators

jaffa225man
Quest Studios Veteran
Quest Studios Veteran
Posts: 169
Joined: Mon Jul 13, 2015 6:26 pm
Location: Chippewa Falls, Wisconsin

Re: Qmidiroute patched for some GS use

Post by jaffa225man »

Ari wrote: Mon Oct 11, 2021 5:33 pm So I have a question:
What does this thing do? I don't mean any disrespect, since you obviously put a lot of work into this program, but I really get lost in all the technobabble...
Could you give a brief summary, preferably in layman terms?
Sure, and thank you for the interest! I hope this is less technobabble with just enough detail.

In the simplest terms, it is a realtime editor for MIDI messages. It's graphical, so you can setup a conversion rule on each of its tabs. I connect it between whatever MIDI game or software would send MIDI to my sound modules normally, and the sound modules themselves. Then, whatever qmidiroute is setup to convert, it does.

Basically, I wanted a workaround for all the slight oddities that MIDI devices have, and I thought a program that anyone can download would be more accessible than perfecting my "transMIDIfier" microcontroller edit device for public use. Programming this was also less difficult than trying to build a full display and input into my transMIDIfier to support all the options I wanted to have. Of course, since my operating system of choice (GNU/Linux ) runs on the raspberry pi, it still may be used as an external device between the computer with the game or music, and any MIDI module(s). For that, the raspberry pi would also need a USB to MIDI adapter.

In particular, I wanted it to fix various issues I've noticed through the years:

1. SysEx delays for the MT-32 (old) (whatever time, in milliseconds, you choose). I've found, through experimentation, 140ms to be enough in most cases.

2. Setting "Note Off" velocities to zero to correct the CM32L and CM-64's unnofficial overflow assign mode (using these modules chained together through their output ports to avoid dropped partials).

3. Converting Program Change numbers to any other, along with any chosen Variation. I've created examples of this, using it to emulate capital tone fallback for the SC-33, and SC-55mkII, and to use fancier instruments on the INTEGRA-7 instead of its GS or GM2 banks which would be default. Similarly, files I've created for the SC-8850 spice up the variety a bit with layered electric pianos replacing any piano, and Wide French horns replacing any french horns.

4. Drum set messages are recognized in order to convert from and to any MIDI standard (GS, XG, GM2). I used this, along with Program Change conversion (for GS/XG common Sound Effects differences) to create converters from and to GS and XG. So with that, you can play XG or GM2 music on your SC-55/SC-88/SC-88pro, or GS music on your MU50/MU80.

5. System Exclusive messages (SysEx) can be removed or changed. Edits can even be done to bytes at a certain address without changing the rest of a message. This is also used in the GS/XG converters, along with converters for certain volume edits for the MT-32 family (to avoid the MT-32 (new), CM-32L, & CM-64's digital volume overflow issue).

6. Converting any type of MIDI message to most others. One example is that any MIDI keyboard note, could be converted to send a SysEx message, so you could play some keys on your MIDI keyboard to send different SysEx messages. Similarly, controllers (CCs) can be converted to send SysEx output too. The reverse works too: SysEx (say a GS Reset message) can be converted to send reverb controller messages, etc.

There's a lot more conversion examples I could list, but this is probably as good an overview as any. I would like it to be as adaptable in conversion capabilities as possible, and think it's really getting there.
Ari
Quest Studios Veteran
Quest Studios Veteran
Posts: 49
Joined: Wed Nov 11, 2015 10:47 am

Re: Qmidiroute patched for some GS use

Post by Ari »

Thanks for the detailed (and considerably less technical) explanation!
I don't use Raspberry Pi and/or Linux, so it's less relevant for me, but kudos for the effort! Keep up the good work.
I would love to hear/see some examples of what can be done with this.
jaffa225man
Quest Studios Veteran
Quest Studios Veteran
Posts: 169
Joined: Mon Jul 13, 2015 6:26 pm
Location: Chippewa Falls, Wisconsin

Re: Qmidiroute patched for some GS use

Post by jaffa225man »

Ari wrote: Tue Oct 12, 2021 6:33 am Thanks for the detailed (and considerably less technical) explanation!
I don't use Raspberry Pi and/or Linux, so it's less relevant for me, but kudos for the effort! Keep up the good work.
I would love to hear/see some examples of what can be done with this.
You're quite welcome, and thanks for the encouragement! I have actually been considering doing a youtube video since it was kind of suggested by quattj in the Technical Support / Knowlegebase Forum:
quattj wrote: Sat May 08, 2021 4:05 pm I'd be curious to see it (though I have windows, so I'd be relegated to watching a video or viewing screenshots)
It would be a first for me, though, since I've not wanted to publicly appear online before. I think you've tipped me over the edge, but it'll probably take a while to plan, create, edit, and upload.
jaffa225man
Quest Studios Veteran
Quest Studios Veteran
Posts: 169
Joined: Mon Jul 13, 2015 6:26 pm
Location: Chippewa Falls, Wisconsin

Re: Qmidiroute patched for some GS use

Post by jaffa225man »

Sorry, changes have been made to my qmidiroute-0.5.2 patch again.
Yesterday, I found and fixed a bug and added something to XG translation that the SC-8850's XG Lite Mode doesn't even recognize.

I noticed an XG example file (Aoi.mid) not setting a channel to drums through qmidiroute that should have been. I tracked it down to a SysEx message that was unknown to me: one that can set a channel to either drums or instruments for XG. Qmidiroute recognizes it now that I've deciphered it, and is working as it should on Aoi.mid, the only file I know it exists in.

The bug relates to unmatched SysEx delays not working after any MIDI reset, which was just the case of a variable not being reinitialized.
jaffa225man
Quest Studios Veteran
Quest Studios Veteran
Posts: 169
Joined: Mon Jul 13, 2015 6:26 pm
Location: Chippewa Falls, Wisconsin

Re: Qmidiroute patched for some GS use

Post by jaffa225man »

Sorry, I bug-fixed two issues and replaced 0.5.2 again!

Yesterday, I noticed the upper limit of pitch-bend values should be 8191 (the lower limit is -8192) so I've set a new default and maximum for that.

In relation to conversions from non-SysEx to SysEx, I became aware of duplicate messages being created (while selected not to) when the output message has a smaller range than the input. That's because I was only testing the input for changes to decide when to skip writing the SysEx message, in order to save on CPU cycles. I fixed it by comparing the entire created SysEx message for changes every time, and it still isn't a CPU hog.
jaffa225man
Quest Studios Veteran
Quest Studios Veteran
Posts: 169
Joined: Mon Jul 13, 2015 6:26 pm
Location: Chippewa Falls, Wisconsin

Re: Qmidiroute patched for some GS use

Post by jaffa225man »

Ari wrote: Tue Oct 12, 2021 6:33 am Thanks for the detailed (and considerably less technical) explanation!
I don't use Raspberry Pi and/or Linux, so it's less relevant for me, but kudos for the effort! Keep up the good work.
I would love to hear/see some examples of what can be done with this.
quattj wrote: Sat May 08, 2021 4:05 pm I'd be curious to see it (though I have windows, so I'd be relegated to watching a video or viewing screenshots)
There, it's uploaded! It's probably overly informative, but I wanted to cover a lot. I'm not one for public speaking and this gave me that same daunting trepidation. I hope it helps anyone curious.

Here it is: https://youtu.be/5pIb506QipY
Ari
Quest Studios Veteran
Quest Studios Veteran
Posts: 49
Joined: Wed Nov 11, 2015 10:47 am

Re: Qmidiroute patched for some GS use

Post by Ari »

Thanks man, I'll check it out. :)
jaffa225man
Quest Studios Veteran
Quest Studios Veteran
Posts: 169
Joined: Mon Jul 13, 2015 6:26 pm
Location: Chippewa Falls, Wisconsin

Re: Qmidiroute patched for some GS use

Post by jaffa225man »

Ari wrote: Wed Nov 03, 2021 2:42 am Thanks man, I'll check it out. :)
You're quite welcome, and thanks for the interest! Sorry, I hadn't noticed your response until now; for all I know you've already seen it. It's not been very watched, so I have a feeling my slow thought formulation that night has been too boring for most people. The table of contents in the description, will help everyone skip my annoying explanations to just hear music examples, but I'm not sure people have noticed it.
jaffa225man
Quest Studios Veteran
Quest Studios Veteran
Posts: 169
Joined: Mon Jul 13, 2015 6:26 pm
Location: Chippewa Falls, Wisconsin

Re: Qmidiroute patched for some GS use

Post by jaffa225man »

Happy Holidays everyone! :)

I just replaced it again with a couple bug-related improvements. The main issue I corrected is when an XG drum is set without following it up with a program change (rare, but in at least one XG file I have), it was not sending GS drum enable SysEx when specified. Also, I noticed a double-free error on one of the extra messages inserted, so I changed the majority of the remaining inserts into pointers to be fully managed and handled properly.
jaffa225man
Quest Studios Veteran
Quest Studios Veteran
Posts: 169
Joined: Mon Jul 13, 2015 6:26 pm
Location: Chippewa Falls, Wisconsin

Re: Qmidiroute patched for some GS use

Post by jaffa225man »

Today there is another cleanup re-release of 0.5.2 which fixes two glitches (viewtopic.php?f=4&t=17790&p=18655#p18655). One falsely detecting a SysEx message in "rose in the gun sight.mid" (F0 41 10 42 12 40 03 15 00 28 F7) as a GS drum disable message. And the other glitch was where {Drum,Program}Forwarding rules existing didn't remove their conflicting unmatched CC#0 and CC#32 from unmatched output.

Here are some of my .qmr file changes:
I noticed ZUN's th5_21.mid not working on the qmidiroute INTEGRA-7 map. It turned out to be a doubled up single SysEx message early on: f0 41 10 42 12 00 00 7f 00 01 f7. Removal of it works great! Also, I fixed a th1_04.mid issue in the INTEGRA-7 map, and all the SC-55 maps where Wind2 from the SC-8850 was being set to Seashore, due to its variation fallback and nonexistence in the sound modules. I remapped it in all those files to variation 3 (Wind), since that makes far more sense. ;)

The INTEGRA-7 map also has the GM Orchestra drums re-forwarded to its actual SN-D Orchestra drums, to match more closely to that intent.

I noticed in all the SC-55mkII variation fallback files that they skip over some nonzero variations: "PC83-107V>0FB". I think my problem was that the SC-55mkII manual I have doesn't list the variations properly, but the SC-8850 manual has them to refer to. With that in mind, I compared what I had mapped in the SC-55mkII variation fallback files to the SC-8850's SC-55 map column.

I also decided to make all the SC-55 maps forward even capital tones (varition 0) to be sure that bank is always properly set to 0 for more modern SMFs, although the umatched output no longer sends duplicate conflicting CC#0 and CC#32 messages.

MT-32-for-GS-Pan-Reversal-Insert-First.qmr and MT-32-for-GS.qmr can be used by running two qmidiroute processes together in series to approximate MT-32 music on GS synthesizers, but of course it is most accurate when using MIDI files that don't program their own sounds for the MT-32.

Finally, I added three files to team up an SC-55mkII with an SC-33 (or similar SOUNDCanvas lacking the MT-32 sounds) to approximately double the polyphony. The idea is to split the odd channels to the SC-55mkII on ALSA output port 1, and even channels to ALSA port 2 on the SC-33 (When MT-32 sounds are to be played they are always routed to the SC-55mkII on port 1 too.) The use of these files requires three running instances/processes of qmidiroute connected like so: SC-55-and-SC-33-splitting-channels0-XG-for-GS.qmr's port 0 (input) should be connected to the MIDI playing program or the real MIDI input port that will be playing music. Its port 1 (output) should be connected to SC-55-and-SC-33-splitting-channels1-SC-55mkII-variation-fallback.qmr's port 0 (input), and that instance's port 1 (output) should be connected to SC-55-and-SC-33-splitting-channels2-split.qmr's port 0 (input). That final instance's port 1 (output) connects to the SC-55mkII's MIDI input port, while this final instance's port 2 (second output) connects to the SC-33's MIDI input port. In that configuration they should be able to play anything GM, GS, or XG (with polyphony issues still possible, but far better).
Post Reply