First, since I forgot to mention it before now (in this thread), version 0.5.0 added the ability to remove SysEx messages when using the "SysEx Edit" type for both Input and Output. To do so, SysEx Input would contain the message to remove, and its corresponding SysEx Output message would be left blank or a space. As otherwise illustrated before, other messages can still be edited on input and output, separated from each of the two messages just described, by a comma.
To use the silly example of removing MT-32 resets, while at the same time editing GS resets to actually be MT-32 resets this could be on input (without the quotes):
"f0 41 10 16 12 7f 01 f7, f0 41 10 42 12 40 00 7f 00 41 f7"
and this on output (still without quotes):
", f0 41 10 16 12 7f 01 f7"
That would do it. Qmidiroute would only send an MT-32 reset to its output port, when a GS reset is sent to its input port.
And, the trick above still exists in the current version. Since it was purposeful, although I forgot to tell anyone until recently, I won't be removing it in any release.
Now for today's release: Version 0.5.2 is finally complete and perfect, although eventually It's pretty likely that I'll find another future necessity to add because programming this has been addicting and I'm a perfectionist. It feels so capable now, that I considered calling it 0.6, but time will tell.
Here it is:
To build it, you'll still probably want to follow this post (while swapping in the current version):
I hope this release finds everyone well, and as always, thank you for using it!
Read further for my pedantic release notes:
This time, many possible GUI improvements were noticed, added and/or fixed:
I finished implementing the output modes since I noticed them lacking, and "Offset" and "Reverse, Offset" wouldn't have worked for "GS Bank" or "GS Variation" (although I'm not likely to ever need those modes for them). indexOut wasn't my creation in the first place, but I did co-opt it for "GS Variation" (and more), so it's interesting that the prior author, in adding it, didn't notice it wasn't working either (for offsetting controller numbers, etc). Although, that use, too, seems esoteric so I shouldn't really be surprised.
A very useful new repair allows for switching the Input or Output Type temporarily, while storing user-set settings to variables that are recalled when necessary. It had been already implemented, but only for the Output Mode controls. For instance, now Pitchbend's "Pitch" is by default set to its maximum range (-8192 to 8192), and if either of the values are changed, before going to another Input or Output Type, that user-set range is restored when back on the Pitchbend type. It isn't every type that gets its own variable, though. These recall variables that I created are for when a given field's range, or use, changes. Anyway, switching types is now safer, without needing to worry about remembering the values you had set. Before, they may have been reset by simply looking at another Input or Output type's fields. The variables are in runtime memory only, though, so if you close qmidiroute or open a different qmr file, they're lost and you will still have to reset any hidden, unsaved, values again. Only fields shown on each rule, are saved to a .qmr file when you do.
An output channel range was added for the very specific use of "SysEx Edit" Input type to "Controller" Output type, so that you only need one rule to create up to 16 controller messages from just one matching SysEx input message.
Many deprecation warnings by my more recent version of the QT library (5.15.2) were resolved for future-proofing.
Drum Forwarding now matches drums based on XG and GM2 drum set controller messages being input (as well as the GS drum detection I already had in previous versions). For these controllers to be used for this drum setting purpose, though, the last MIDI initialization standard sent to qmidiroute's input port, must have been an "XG System On", or "GM2 Reset", respectively. Since SysEx is already supposed to be "Exclusive" to a vendor, though, the GS drum SysEx is used to match drums, no matter what the last recognised MIDI standard was.
To simplify multi-device single .qmr file creation further, I added a "Forward Mode" filter to the forwarding rules so that now they can match only messages based on the last MIDI initialization standard sent to qmidiroute's input port. The choices are "All" (just like it had worked before "Forward Mode" existed, forwarding everything), "MT-32, GS & GM1/2", "MT-32, GS & GM1", "GS & GM1/2", "GS & GM2", "GS Only", "MT-32 Only", "GS, XG & GM1/2", "MT-32, XG & GM1", "XG & GM1/2", "XG & GM2", "XG Only", "GM1/2 Only", "GM2 Only", and "GM1 Only". For example, an "XG Only" SysEx Edit In and Out rule will notice an XG System On message (f0 43 10 4c 00 00 7e 00 f7) and send that (or its specified edit) to the output port, and continue to send SysEx (or, as specified, edits of it) until an MT-32 Reset, GS Reset, GM1 Reset, or GM2 Reset is encountered. This feature can also be used with the "SysEx Forward", "Program Forward" and "Drum Forward" rule types, to send unedited SysEx, Programs/Instruments, and Drums to a specified output port with your chosen bank, variation, and PC#, etc..
SysEx Edit's "SysEx" text boxes can each now use an asterisk ("*") to match any of one or more bytes in a SysEx message. If you have an asterisk both in input and output, whatever is seen on input where the asterisk existed (if the rest of the message is matching), is copied to wherever the output message contains the asterisk. However unlikely useful that is, it follows traditional asterisk use on the GNU/Linux & UNIX command line utilities, so that's what I tried to duplicate. I created it simply for use as an easy match-all (or match-most) for SysEx messages, though. As an example, some XG messages mess with the SC-8850, when it isn't in XG-Lite mode (due to deleting the "XG System On" message, or if that's otherwise missing). I noticed the problematic messages all began with "f0 43 10 4c" so, wanting to remove them, now I can put this on SysEx Edit's Input, but first, here, I match "XG System On" (f0 43 10 4c 00 00 7e 00 f7) to change it:
f0 43 10 4c 00 00 7e 00 f7, f0 43 10 4c * cks-1 05:08 f7
Then on SysEx Edit's Out, I have this "GS Reset", and then a comma-separated empty message (without the quotes):
"f0 41 10 42 12 40 00 7f 00 41 f7,"
Which converts "XG System On" to "GS Reset", and the empty message simply removes all remaining messages starting with "f0 43 10 4c". The input's "cks-1 05:08 f7" doesn't actually test the input checksum, which is good (since it would be looking to match Roland's, but Yamaha's should be on their messages, here) I just like to always include it for any sitation for clarity (and since it is a placeholder which would affect output if edit replacements existed).
Here's another nonsensical example to illustrate how the asterisk replaces if it's on both input and output.
If you have this in Input SysEx Edit:
f0 41 10 42 12 * cks-1 05:08 f7
And this in Output SysEx Edit:
f0 41 10 42 12 02 88 * 11 cks-1 05:08 f7
And send it a GS Reset (f0 41 10 42 12 40 00 7f 00 41 f7), you get this from qmidiroute's output port:
f0 41 10 42 12 02 88 40 00 7f 00 11 26 f7
To begin to pick apart how that works, the asterisk on input is between the 0x12 byte and the checksum placeholder/definition ("cks-1 05:08") byte. Since the GS Reset message matches the bytes up to the asterisk in the Input SysEx Edit box (these match: "f0 41 10 42 12"), the asterisk becomes a placeholder for the further bytes read from the GS Reset message, directly after those beginning bytes that were already matched. That is, the asterisk becomes its "40 00 7f 00". The asterisk ends at the 0x00 because the Input SysEx Edit box specifies that after the asterisk, there's a checksum placeholder/definition and then a 0xf7.
Now that we've matched the GS Reset, it can be edited for output. The matched start of the message "f0 41 10 42 12", is outright replaced by the Output SysEx Edit box's bytes before its asterisk, which is "f0 41 10 42 12 02 88". Now those four previous asterisk placeholder bytes are output: "40 00 7f 00". Next, it's the 0x11 which comes after the asterisk in the Output SysEx Edit box. And finally, the Output SysEx Edit box says there's a new checksum to be written, along with the 0xf7. And sure enough, when you put all that together, you get what was suggested above: "f0 41 10 42 12 02 88 40 00 7f 00 11 26 f7"
Like I said, asterisks for SysEx replacement don't seem too useful, but it follows (as closely as I could come up with) the standard GNU/Linux asterisk command logic.
SysEx Edit Output can now be used with many other Input Types, using the SysEx range syntax as your variable in the message (such as "00-7f", which is 0-127 decimal, so perfect for most cases). Using a range means you'd want to use the "cks-1 05:08" syntax too, otherwise Roland would ignore it due to a bad checksum. If, instead, you opt not to include a range in the message, it will be sent exactly as you wrote it, without any changing bytes.
"Note" Input uses the note/key played for the variable range byte.
"Note Off" Input, similarly, uses the lifted note/key to create the range byte.
"Controller" Input uses the controller "Value" (not the CC#, but that is one of the match limiting criteria).
"Channel Aftertouch" Input uses the aftertouch (pressure) "Value" for obvious reasons.
"Polyphonic Aftertouch" Input uses the aftertouch velocity (pressure) "Value" too.
"Pitchbend" Input uses the "Pitch", of course.
"Program Change" Input uses the Program Number (PC#) "Value".
This rule's setup allows limits to how often SysEx messages are output (set in milliseconds, up to 2000ms maximum, which is 2 seconds). Setting that to 0ms doesn't limit messages at all. While limiting, messages are simply dropped, except for the last one captured, that will play either when the time limit runs out (if other messages are being sent through) or just before the next message qmidiroute receives on input is played. You can also "Remove Sequential Dups" (duplicates) by setting its box to "1", while with a "0" duplicates will always output. With it enabled to "1", for example, an Input Note, Output SysEx Edit rule would only output the SysEx message set when you play different keys in series (when you have both side's ranges allowing for it - the Note range set to, perhaps, 0-127, and the SysEx range, perhaps "00-7F"). Two presses of the C note would only register once, unless you play something else in between them. I just thought it wiser to limit SysEx repeats from bogging down devices unnecessarily, but you may decide that for yourself by setting "Remove Sequential Dups" on or off (1 or 0).
SysEx Edit as Input can be converted to Controller Output now too, since Spikey made me aware of Reverb and Chorus sometimes being set by controllers (which lead me to want GS Reset SysEx to set them). If the, now standard, range syntax is used in the Input SysEx Edit box (such as "00-7f"), the Output Controller's "Value" (restricted by the Controller Output's "Value" range) will be variably set by whatever input byte occupies its location/address in the actual input SysEx messages. Using no SysEx range means the Output Controller "Value" range will be averaged, so if you want it a certain fixed value, just set both Output "Value" range numbers to that same desired fixed number. Setting a SysEx range, from a lower value to the actual value of a byte you know won't change (such as the 0xf0 start or 0xf7 end, using either "00-f0" or "00-f7" at the start or the end of the message, respectively) would have the same effect, and then you only need to set the Controller's maximum Output "Value" range number to the chosen fixed value.
Drum Forward Output now has a "Generate GS Drum SysEx" option. When "0", nothing new is done, but when set to "1" it converts XG & GM2 controller-set drums to GS by generating the GS SysEx message for Drum enabling (or disabling) on the required channel. These SysEx messages even alternate between Roland's GS Drum Map1 and Drum Map2, so that drum program changes can provide some multi-drumset play on GS.
Finally, all of the .qmr files I previously had released have been updated to be compatible. While doing so, though, I took the liberty of adding two new conversion map files: XG-for-GS-Devices.qmr (add adding its functionality to all of the SC-8850 files), and GS-for-XG-Devices.qmr. For me, the SC-8850's XG-Lite mode seems heavily filtered, and manual conversion this way sounds clearer (and it's nice to be able to use the SC-8850 controls without making everything "Piano 1"). Although many XG files do love to sweep filters, they aren't curtailed with these manual conversions. Some XG filter sweeps are so loud on non-XG devices that I wouldn't have minded, but haven't yet found their precise cause. The INTEGRA-7-SuperNATURAL-1port.qmr converts from XG too, but was simpler to implement, since it doesn't need GS Drum SysEx to set drums on a channel.