Qmidiroute patched for some GS use

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

Moderator: Quest Studios Archive moderators

Post Reply
jaffa225man
Quest Studios Veteran
Quest Studios Veteran
Posts: 72
Joined: Mon Jul 13, 2015 6:26 pm

Qmidiroute patched for some GS use

Post by jaffa225man » Mon Nov 11, 2019 12:44 pm

I bought a D-05 and wanted to experiment with it by playing my usual midi playlist. Sadly, I didn't know of a way to automatically forward certain program numbers to it. For instance, I wanted to send all piano (PC#1-6) to it, while using the SC-8850 for the rest. Qmidiroute can be used, but based on the channel, not the program number, and that would mean creating a new configuration for every midi file that changes where the pianos are. Anyway, since a solution wasn't immediately apparent, I decided to build this functionality into qmidiroute with another patch. It's finally done!

As far as features go, it now has this "Program Forward" map, where an input value (PC#, 0-127) may be matched to output to, in addition to the alsa port mapped to whatever device, a specific (or offset) channel, a specific value PC# (or range), and a fixed specific GS Variation (0-65) (or -1 can be used to just pass the input variations).

I also added a "SysEx Forward" map so that the SC-8820 can be on equal footing when used with the SC-8850. It takes no input arguments, and just outputs to the specified port.

SysEx Forward is also useful when used additionally with the "Drum Forward" map. Drum Forward takes an input channel range and matches, like Program Forward, with the PC#. For simplicity it just outputs to the same channel as was input. SysEx Forward is needed because GS SysEx can be used to alter any channel into becoming drums. Without SysEx Forward, drums may be forwarded to a channel other than 10 and would play as piano or whatever instrument happened to be there. Anyway, Drum Forward's output value (PC#) range can be set (0-127) to select the wanted Drums. Of course, the alsa port is set to specify the output device.

Qmidiroute has 2 virtual output ports by default, but if you need more, the amount can be given on the command line with -p, like so:
qmidiroute -p3

There you have it! The uses are many, but I've considered testing certain SC-8820 instruments along with the rest on the SC-8850. So far, I've just been playing with the D-05 and SC-8850, though. It's a neat perk to be able to "Program Forward" SC-8850 default instruments into more favorable variations, such as "Wide FreHrns", without having make modifications to every MIDI file. I'll include a test qmidiroute mapping that plays with that idea a bit, sending pianos 1-6 (0-5) to SC-8850 Part A as "St.Soft EP", and to Part B as "EP Legend", while French Horns are all changed to "Wide FreHrns" and play on both Part A and Part B. To set this up, I use aconnect to connect the SC-8850 parts to the virtual ports, in a terminal, like so ("aconnect -l" will list all ports available):
aconnect 129:1 32:0 ; aconnect 129:2 32:1
Also, you need to be sure your player is connected to qmidiroute's input (which in my example is 129:0), and that, likely, is done through the GUI of the player, but otherwise could be done with aconnect similarly to the above commands (where 14:0 is the player's output port):
aconnect 14:0 129:0

Again, I based this patch on the standard debian qmidiroute 0.4.0 source, but have also included one that will incrementally patch on top of my previous Note Off patch. Both retain the Note Off map functionality too, to fix the CM-32L/CM-64 overflow assign.

I hope it's useful to someone other than me. Enjoy:
qmidiroute-0.4.0-progch-port-forwarding-patches.7z
(13.5 KiB) Downloaded 510 times
Edit 2019-11-13 Found 2 bugs already, and fixed them. I'm sorry to those of you that already downloaded it, if you noticed what I just did: After my gs-reset.mid file, with the example .qmr file the non-variation SC-8850 Parts were being changed to variations 8, and 10). Also, the Drum Forward was stuttering because it was checking for changes in the variation. Drums not having a variation, it was never setting a value. What a silly mistake, but I guess that's what last minute changes lead to... more changes after tests are repeated.

Final Edit (I hope, for a long time) 2019-11-14 After the drums were working, I noticed and fixed a bug where the GS Map being set on drum channels would be retained when the user specifies one that exists in a more recent map, so just like with standard GS instruments, I decided to let the user choose which map (through their module's front panel buttons) by first sending the drum map bank as "0" (and rewriting all possibly conflicting changes) when the GUI-set output PC# ("Value") maps to any PC# higher than zero.

Sorry for the last-minute changes and thanks if you're trying it out,

Luke

Post Reply