alsamodular-devel — AlsaModularSynth Developer

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

An edit today: I hadn't considered before that the default volume of each
part is set to a standard on each reset command (MT-32, GM1, GM2, GS, &
XG). So I made a slight modification and updated the files without changing
the version. The prior 0.5.4 version wouldn't use the Volume Multiplier
when no CC#7 was received, but this change corrects that. The MT-32 resets
each part volume to 80/100, while all the rest of the reset types set part
volumes to 100/127. With this in mind, the MT-32-for-GS.qmr file also
contains an update to provide proper volume conversion (the Volume
Multiplier set to 1.27 for every forwarded program and drum).

Thanks!

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

I have another release at last, almost a year later!
The new version 0.5.4 (Sorry, I made a typo in my prior release that said
"1.5.3" when I meant "0.5.3".) is hosted at midimusicadventures
queststudios forum in this post:
https://www.midimusicadventures.com/phpbb/viewtopic.php?p=18715#p18715

When asked to capture the INTEGRA-7's SuperNATURAL conversion of the Age of
Empires soundtrack on a vogons private message, I realized that its Bag
Pipes were being set lower than I'm used to on the Sound Canvas modules.
It had to do with CC#7 setting the volume too low, and maximizing the
velocities of notes on the SuperNATURAL Bag Pipes wasn't enough.  Now
there's a "Volume (CC#7) Multiplier" below the aforementioned "Velocity
Multiplier" on the Output side for rules that output Program Forward and
Drum Forward.  For the Bag Pipes I settled on 2.00 times the set volume,
and although it was only tested on the AOE soundtrack I expect it will be
valid for most GM/GS/XG files using the SN-A Bag Pipes on the INTEGRA-7.
Sadly, this again means that previous .qmr save files are incompatible,
unless every rule has a new line containing only a 1, between the velocity
multiplier's line and the input SysEx message text line.  Of course, again,
I've updated all my included .qmr files with this change.

Aside from that, this is the first release that I verified will compile on
raspbian using the same method that I suggest at
https://www.midimusicadventures.com/phpbb/viewtopic.php?p=18511#p18511.

Newer and likely older versions of raspbian should work, although my
raspberry pi is using version 8.0, according to /etc/debian_version on it.

It still builds on my amd64 Debian install too, which is my main use, so
it's a must for me.

Enjoy! :)

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

I have a new release of QMIDIRoute today and I have decided to increment
the version to 1.5.3 at last:
https://www.midimusicadventures.com/phpbb/viewtopic.php?f=4&t=17790&start=20#p18702


The build instructions at
https://www.midimusicadventures.com/phpbb/viewtopic.php?f=4&t=17790#p18511
are still good to follow except for the obvious version number you'd need
to substitute in each command that has it.

Darry on this vogons post piqued my interest in adding RA-50->"MT-32 (new)"
support with an option to expand All Notes Off messages into the component
Note Off messages that would be needed:
https://www.vogons.org/viewtopic.php?p=1099519#p1099519.

That option breaks the .qmr save format again (the first line needs an
extra number separated by a space), but I've updated all my previously
released .qmr's for that too.  The Unmatched rule/tab has a new check box
to enable the expansion of the All Note Off messages.

In addition to the edits for that purpose, I updated the capital tone
fallback in any files that had it to more accurately sub-tone fallback,
with what I consider minor improvements:

I set up capital tone (variation 0) fallback for programs 1-120 on
variations 64-126, and programs 121-127 on every unmatched variation
because I wouldn't want silence for anything, although the SC-55 manual
documenting it indicates they should be.

Also, drum programs 65-127 fallback to STANDARD (pc#1) to emulate my likely
valid CM-500's drum fallback.  Anyway, again, I wouldn't want silence for
anything. :)

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

Today there is another cleanup re-release of my qmidiroute 0.5.2 patch
which fixes two glitches (
https://www.midimusicadventures.com/phpbb/download/file.php?id=59).  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 included .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).

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

Happy Holidays everyone! :)

I just replaced it again (now at
https://www.midimusicadventures.com/phpbb/download/file.php?id=55) 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.

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

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.

Those who don't frequent the midimusicadventures.com queststudios archive
forum can find the current patch here:
https://www.midimusicadventures.com/phpbb/download/file.php?id=54

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

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.

The link for those not visiting the queststudios archive forums at
midimusicadventures.com:
https://www.midimusicadventures.com/phpbb/download/file.php?id=53

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

Whoops, I noticed I'd forgotten Program Change's section... It's been fixed
right away, but not quite quick enough for one person. Sorry to you!

Non-midimusicadventures.com questudios archive forum users:
https://www.midimusicadventures.com/phpbb/download/file.php?id=52

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

I have again released a last-night-noticed fix to a bug (which, this time,
was created during my first fix release).  And again, I replaced my 0.5.2
version link with it.  Again, I'm sorry to the early adopters.  This repair
only changed eight lines, so I imagine no harm could be done, and I tested
it with everything I think it applies to... Hopefully, those are not my
famous last words. ;)  Well, they literally can't be since I haven't
described what was fixed yet, yeah!

Here's the download link for those who don't follow the midimusicadventures
queststudios archive forums:
https://www.midimusicadventures.com/phpbb/download/file.php?id=51

Anyway, I noticed that XG drums on channels other than 10, were being
forwarded as non-drums, but it must have also affected Program Forward
(since the same four lines are used in both sections).  Anyway, Program and
Drum Forwarding needed their isMap() return(false) conditions corrected.  I
wonder if/when I'll be able to easily conceptualize the negative
conditionals at the end of isMap().  If any of these conditions is true,
isMap() returns false.  That simple negation has lead me to much too much
uncomfortable squirming.

I hope this is good news for anyone who tried it and noticed the flaws, and
not as much of a chore as it is for me.

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

Sorry to send another message, but if you don't visit the
midimusicadventures post, you'll need this new link:
https://www.midimusicadventures.com/phpbb/download/file.php?id=49

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

Sorry to have released it with a glitch (especially to the one or two
people who already downloaded it), but I noticed what seems a long
standing one (at least it's in 1.5.1 for sure), and just fixed it,
replacing the original flawed version 0.5.2.  It was apparent when I
tried the SC-55 variation fallback qmr files, yesterday, and was
getting incorrect variations from the unmatched output.  I sorted it
out as soon as I could, and hope that's without introducing new bugs.
So far, the edits didn't hurt anything I've tested, and I tried to
test everything it could affect.

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

First, since I forgot to mention it before now, 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:
https://www.midimusicadventures.com/phpbb/download/file.php?id=48
(Or in the original post here):
https://www.midimusicadventures.com/phpbb/viewtopic.php?f=4&t=17790&p=18655#p18655

To build it, you'll still probably want to follow this post (while swapping
in the current version):
https://www.midimusicadventures.com/phpbb/viewtopic.php?f=4&t=17790#p18511

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.  Using a non-differing SysEx
range (a hyphen between two of the same number) would have the same effect,
assuming that particular location/address has that value or it would be
unmatched.

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.

[Alsamodular-devel] AMS 2.2.0 LADSPA discovery

[Frank K. <goe...@ya...>]

Hello Guido et al.,

I think in the current git version (and 2.2.0) there is a bug in the 
LADSPA search routine.

Everything is fine when your environment variable is 
LADSPA_PATH=/usr/lib/ladspa.

But it appears that in my ~/.bashrc there is

LADSPA_PATH=$LADSPA_PATH:/usr/lib/ladspa

and no previous (system-set) definition of it. The current search in 
ladspadialog.cpp fails to remove the colon in this case (where 
LADSPA_PATH is :/usr/lib/ladspa )

The following change fixes this for me:

@@ -104,7 +104,7 @@ LadspaDialog::LadspaDialog()
      if (colon >= 0) {
        ladspadir = ladspapath.substr(lastcolon + 1, colon - lastcolon - 1);
      } else {
-      ladspadir = (lastcolon) ? ladspapath.substr(lastcolon + 1, 
ladspapath.length() - lastcolon - 1)
+      ladspadir = (lastcolon > 0) ? ladspapath.substr(lastcolon + 1, 
ladspapath.length() - lastcolon - 1)


Does anybody agree with this?

Thanks and keep up the good work

Frank

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

First, please expect my previous message's build instructions to always be
necessary to compile my qmidiroute patches.  There's another I just
released today.  It may continue to be improved as I come up with new
ideas, but now it's version 0.5.1, and is available at
https://www.midimusicadventures.com/phpbb/viewtopic.php?f=4&t=17790&p=18542#p18542

These are the three main changes I made:
1. SysEx Edit: If you have multiple offset values that do (or could) occur
on the same message, you can now group them with a new syntax to denote it.
That is, wrap each comma-separated message in parentheses. Because just
describing it can seem complicated, I'll give the example of my first
reason for it. MT-32 family Part Volumes are set through a range of
semi-close addresses, so in at least one occurrence, they might be just in
a single, long, SysEx message like so (from KQ4.SYX):
f0 41 10 16 12 03 00 00 01 0c 18 32 0c 00 01 00 64 06 00 00 00 00 00 00 01
30 18 32 0c 00 01 00 00 07 00 00 00 00 00 00 01 14 18 32 0c 00 01 00 64 0a
00 00 00 00 00 00 01 1d 18 32 0c 00 01 00 60 09 00 00 00 00 00 00 00 3b 18
32 0c 00 01 00 64 07 00 00 00 00 00 00 00 20 18 32 0c 00 01 00 64 05 00 00
00 00 00 00 00 24 18 32 0c 00 01 00 64 0b 00 00 00 00 00 00 01 3a 18 32 0c
00 01 00 50 0e 00 00 00 00 00 00 31 f7

I include the old Master Volume translation first, but then (contained in
parentheses) lower all the parts' volumes. Here's what goes in SysEx Edit
Input:
f0 41 10 16 12 10 00 16 00-64 cks-1 05:08 f7, (f0 41 10 16 12 03 00 08
00-64 cks-1 05:08 f7, f0 41 10 16 12 03 00 18 00-64 cks-1 05:08 f7, f0 41
10 16 12 03 00 28 00-64 cks-1 05:08 f7, f0 41 10 16 12 03 00 38 00-64 cks-1
05:08 f7, f0 41 10 16 12 03 00 48 00-64 cks-1 05:08 f7, f0 41 10 16 12 03
00 58 00-64 cks-1 05:08 f7, f0 41 10 16 12 03 00 68 00-64 cks-1 05:08 f7,
f0 41 10 16 12 03 00 78 00-64 cks-1 05:08 f7, f0 41 10 16 12 03 01 08 00-64
cks-1 05:08 f7)

For this to work properly, it is important to match each comma-separated
input message to the same number of comma-separated messages for the
output, including putting the parentheses around the same number of
messages for the output as was in the input:
f0 41 10 16 12 10 00 16 00-30 cks-1 05:08 f7, (f0 41 10 16 12 03 00 08
00-5a cks-1 05:08 f7, f0 41 10 16 12 03 00 18 00-5a cks-1 05:08 f7, f0 41
10 16 12 03 00 28 00-5a cks-1 05:08 f7, f0 41 10 16 12 03 00 38 00-5a cks-1
05:08 f7, f0 41 10 16 12 03 00 48 00-5a cks-1 05:08 f7, f0 41 10 16 12 03
00 58 00-5a cks-1 05:08 f7, f0 41 10 16 12 03 00 68 00-5a cks-1 05:08 f7,
f0 41 10 16 12 03 00 78 00-5a cks-1 05:08 f7, f0 41 10 16 12 03 01 08 00-5a
cks-1 05:08 f7)

That will remap Master Volume 0-100 to 0-48, and each Part Volume 0-100 to
0-90. In my real test, I had Part 2 outputting 5a-5a (a constant 90), so
the muted timpani that Ari discovered wasn't. I'm happy to report that
KQ4_5.mid played without clipping, after also adding a rule tab to
eliminate all controller 7 messages, by sending them to an unused port.
Here's the actual output when using the examples above (Part 2-timpani is
muted, but otherwise it should serve help understanding):
f0 41 10 16 12 03 00 00 01 0c 18 32 0c 00 01 00 5a 06 00 00 00 00 00 00 01
30 18 32 0c 00 01 00 00 07 00 00 00 00 00 00 01 14 18 32 0c 00 01 00 5a 0a
00 00 00 00 00 00 01 1d 18 32 0c 00 01 00 56 09 00 00 00 00 00 00 00 3b 18
32 0c 00 01 00 5a 07 00 00 00 00 00 00 00 20 18 32 0c 00 01 00 5a 05 00 00
00 00 00 00 00 24 18 32 0c 00 01 00 5a 0b 00 00 00 00 00 00 01 3a 18 32 0c
00 01 00 48 0e 00 00 00 00 00 00 75 f7

2. Program & Drum Forward now has a Velocity Multiplier value to help in
supporting non-GM/GS compliant instruments. If some just seem a little
quiet or louder than you are used to, just increase or decrease the
multiplier. 1.00 is the default. With it, output velocities remain the same
as input. I thought this might help with some non-GS/GM quiet sounds on the
INTEGRA-7, but haven't remembered which yet.

3. The Unmatched rules tab now has a check box that disables Note Off
Velocity for all (matched and unmatched) messages. I just was thinking that
it would be easy enough to implement now, and allows simpler consolidation
for multi-device maps supporting the CM-32L/CM-64 at the same time as the
Sound Canvas family. Leave it unchecked, and those weird messages will go
through unscathed. I think they're a relic of glitches or flaws in devices,
though, and would be interested to hear of some practical use for Note Off
having velocities set.

Sadly, changes 2 and 3 break the save format again, but I've updated all my
included .qmr files and added a few more I've had kicking around.

Happy Hacking!

  Lucas

Re: [Alsamodular-devel] release 2.2.0 misses tag in repository

[Guido S. <gui...@gm...>]

Am Sun, 28. Feb 2021 um 18:34:13 +0100 schrieb David Runge:

> Hi!

Hi David,

> For the release 2.2.0 [1] there is no matching tag in the git repository
> [2]. Which commit were the release tarballs created from?
> For reproducibility, upstream tracking and transparancy reasons it would
> be really great if you could add the matching tag.

Thanks for the hint, it is published now, was only available in my local
repository.
Guido


-- 
http://wie-im-flug.net/
http://www.lug-burghausen.org/

[Alsamodular-devel] release 2.2.0 misses tag in repository

[David R. <da...@sl...>]

Hi!

I package ams for Arch Linux. For upstream tracking I usually rely on
e.g. git repositories whenever possible to track whether a new release
is out.

For the release 2.2.0 [1] there is no matching tag in the git repository
[2]. Which commit were the release tarballs created from?
For reproducibility, upstream tracking and transparancy reasons it would
be really great if you could add the matching tag.

Best,
David

[1] https://sourceforge.net/projects/alsamodular/files/alsamodular/2.2.0/
[2] https://sourceforge.net/p/alsamodular/ams.git/ref/master/tags/

-- 
https://sleepmap.de

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

I had a fairly hard time installing this on another debian machine of mine
today, so I feel obligated to tell anyone trying this for themselves the
steps I took:

In a terminal, go to the directory the patches were downloaded to
# cd ~/Downloads/

Become root:
# su
& enter your root password
or
# sudo su
& enter your user account password

Extract the patches to /usr/src with something like this:
# 7z x -o/usr/src ./qmidiroute-0.4.0-to-0.5.0-patches.7z

Go where we want to extract the source
# cd /usr/src/

Download & extract debian's source for qmidiroute-0.4.0
# apt-get source qmidiroute

Just to keep the patch level obvious
# mv /usr/src/qmidiroute-0.{4,5}.0

Go into the build directory
# cd /usr/src/qmidiroute-0.5.0

Apply the patch
# patch -p1
</usr/src/qmidiroute-0.4.0-to-0.5.0-patches/qmidiroute-0.5.0.patch

Install some build requirements
# apt-get install qttools5-dev-tools

Sanitize the build system for your install
# aclocal
# autoconf
# automake

To be sure we're using qt5 for everything and rebuild the .moc files for
your specific qt5 version
# export QT_SELECT=5
# qmake -project

Configure it
# configure --enable-qt5

Build it
# make

Install it
# make install

And that's all there is to it, but it sure took me some time to figure out
everything!   I hope not too many people stumbled onto the issues I had,
but if so I'm sorry.

By the way, to any maintainers out there:  If anyone upstream or downstream
wants to merge my patch, I'd be honored and happy.

Thanks and have a happy new year!

On Sat, Nov 14, 2020 at 12:40 AM Lucas E <lul...@ho...> wrote:

> Edit 2020-11-14: Split SysEx messages are recombined so that internal
> checksum calculation will always work. It can be used to standardize MIDI
> file recording with arecordmidi, which would have recorded them split: now
> you can connect qmidiroute between MIDI input ports and your recording
> program to recombine each SysEx message to its original entirety. I also
> took the opportunity to speed up the input function substantially so the
> chances of lost SysEx are minimal (even compared to aseqdump somehow!).
> Audacious-3.4.3 (the last version I can find with the necessary AMIDI-Plug
> ALSA Backend, for some reason) may skip fast SysEx on a file's first play,
> but replaying it (even right away, before it finishes) seems to send all
> SysEx messages. However, aplaymidi, itself, is reliable and always seems to
> send all SysEx.
>
> Since moderation holds my (>40KB) patches for a while, I decided to just
> bypass it this time by linking to my forum post on the midimusicadventures
> queststudios archive.  The patch is in 7-zip archive format there, though:
> https://www.midimusicadventures.com/phpbb/viewtopic.php?f=4&t=17790&p=18491#p18491
>
> It's a fun toy for me, but I hope it's useful to someone else too,
>
>   Lucas
>

Re: [Alsamodular-devel] New release

[Guido S. <gui...@gm...>]

Hi David,

thanks for this reminder, I will work on his topic.

Guido

Am 29.11.20 um 21:24 schrieb David Runge:
> Hi!
>
> I'm packaging ams for Arch Linux.
>
> Currently I have to apply 11 or more patches on top of the last release,
> which has been done in December 2015. Fixing problems on top of that is
> fairly cumbersome.
>
> Would it be possible to tag a new version of this software, so that
> downstreams can rely on more recent source tarballs? :)
> It would be really helpful to have more regular releases of this
> software as this ensures, that it will still integrate with e.g. recent
> qt5 and gcc.
>
> Best,
> David
>
>
>
> _______________________________________________
> Alsamodular-devel mailing list
> Als...@li...
> https://lists.sourceforge.net/lists/listinfo/alsamodular-devel

[Alsamodular-devel] New release

[David R. <da...@sl...>]

Hi!

I'm packaging ams for Arch Linux.

Currently I have to apply 11 or more patches on top of the last release,
which has been done in December 2015. Fixing problems on top of that is
fairly cumbersome.

Would it be possible to tag a new version of this software, so that
downstreams can rely on more recent source tarballs? :)
It would be really helpful to have more regular releases of this
software as this ensures, that it will still integrate with e.g. recent
qt5 and gcc.

Best,
David

-- 
https://sleepmap.de

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

Edit 2020-11-14: Split SysEx messages are recombined so that internal
checksum calculation will always work. It can be used to standardize MIDI
file recording with arecordmidi, which would have recorded them split: now
you can connect qmidiroute between MIDI input ports and your recording
program to recombine each SysEx message to its original entirety. I also
took the opportunity to speed up the input function substantially so the
chances of lost SysEx are minimal (even compared to aseqdump somehow!).
Audacious-3.4.3 (the last version I can find with the necessary AMIDI-Plug
ALSA Backend, for some reason) may skip fast SysEx on a file's first play,
but replaying it (even right away, before it finishes) seems to send all
SysEx messages. However, aplaymidi, itself, is reliable and always seems to
send all SysEx.

Since moderation holds my (>40KB) patches for a while, I decided to just
bypass it this time by linking to my forum post on the midimusicadventures
queststudios archive.  The patch is in 7-zip archive format there, though:
https://www.midimusicadventures.com/phpbb/viewtopic.php?f=4&t=17790&p=18491#p18491

It's a fun toy for me, but I hope it's useful to someone else too,

  Lucas

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

At long last, I've upgraded everything I can think of, and they seem to be
working well!
This changed enough, that I thought a version bump of .1 was justified, so
this patch upgrades debian's qmidiroute-0.4.0 source (or any of my previous
patched versions) to 0.5.0.

A useful SysEx Edit feature is included, along with Channel/Polyphonic
Aftertouch matching.  The 65 variations I'd allowed for the SC-8850 was too
low to use many of the INTEGRA-7's banks, so I expanded them (as well as
the banks) to the full MIDI range of 0-127.  Along with those expansions, I
also tried to align qmidiroute's design better and now Program & Drum
Forwarding can match on input bank and variation, rather than just program
number.  Now any SysEx may be delayed (differently depending on if it's
unmatched, forwarded, or edited).  SysEx Edit also has a rarely needed
feature of removing sequentially duplicate SysEx messages (I encountered it
in some ZUN SC-8850 SMFs).  It's best to not enable it, in most cases,
though as playback containing only one type of reset SysEx message will
only output the first instance.  In debugging some playback on the
INTEGRA-7, I decided to add the option to delay between bank and variation
messages (on the unmatched tab, even though it affects all).  Although I
solved the INTEGRA-7 issue I'd been having another way (holding back these
messages until the program change is received so it is known where to send
them), I read in a Yamaha's "XG Format Music Data Production
Recommendations" ("sisin") manual that XG requires a delay between these
CC0 and CC32 messages (of "1/480", however I haven't researched if that's
in seconds or some other unit, it's on page "5", or 9, of the version 1.15
pdf).  SysEx Edit's syntax is pretty particular.  First, SysEx bytes (in
hexadecimal characters, i.e. "f0" or "F0") are separated by spaces.
Messages are separated by commas ",".  A message may be matched from input
to output as a static list of bytes, or something more fancy may be done.
If you want to change one message into more than one, you can include the
message to be matched on input twice (or more) and for each of those, put a
desired message in output.  In the INTEGRA-7 qmr I'm including, I match
both GS and GM1 resets to replace each with a GM2 reset.  In input, I have
"f0 41 10 42 12 40 00 7f 00 41 f7, f0 7e 7f 09 01 f7", and in output
there's "f0 7e 7f 09 03 f7, f0 7e 7f 09 03 f7".  While that can be useful,
better still is the ability to change a message with ranges.  To get the
MT-32's MASTER VOLUME to a nice level, I match 00-64 (0-100 in decimal) to
0-30 (0-48 in decimal), but since this changes the checksum, we also need
some more special syntax.  I got this idea from the Behringer BCR2000, but
had to expand it for my use: cks-1 05:08 specifies the type of checksum (1
being Roland, 2 or 3 for other types, as the BCR specifies), along with the
address start byte offset as hexadecimal (byte number 0 in the message is
F0), separated from the data start byte offset as hexadecimal (directly
after the address in this case, numbered from 0 on byte F0 again).  So for
the complete example of MASTER VOLUME editing, I have "f0 41 10 16 12 10 00
16 00-64 cks-1 05:08 f7" as input and "f0 41 10 16 12 10 00 16 00-30 cks-1
05:08 f7" as output.  The checksum will be written to the offset cks-# is
from the f7/F7, so in a simple message's case just before the F7.  A longer
message including the MASTER VOLUME byte somewhere in the middle, will
still write the checksum to the byte just before the f7/F7.  If one wanted
to set a constant MASTER VOLUME, that could be done with "f0 41 10 16 12 10
00 16 00-64 cks-1 05:08 f7" as input , and "f0 41 10 16 12 10 00 16 30-30
cks-1 05:08 f7" as output.  If the input edit includes a range, the output
must too, even if the output range creates a constant value. like that.
Either of the checksum (cks-#) or range (-) bytes may be at different
offsets (from input to output), although there's no utility I've seen for
that behavior.  Another change I almost forgot to mention is that the check
boxes in the Event Log portion of the window is now saved, so you may now
disable the logging messages for a headless device and save CPU usage.
While trying to debug some anomalies with SC-8850 variations being set, I
decided to port the entire input procEvents() loop from Qt to pthreads,
just in case Qt wasn't processing input fast enough and missing some
messages.  In the end, I'm not sure if that was the case, but it doesn't
hurt, and I've been wanting to learn pthreads programming anyway, and the
SysEx delays code was made easier by it.

Sadly, the addition of these match types makes save files incompatible with
prior qmr format, so it's a good idea to keep the version you have saved
your previous .qmr files in, to manually migrate values (with each
version's window open) and save new .qmr files.  I updated the ones I'm
including again, though, so no worries if you've just used them.  It's
actually not too hard to examine the saves as text files and edit them
accordingly, but it's probably not for the uninitiated.  By releasing all
these changes at once, I hope to avoid future .qmr file incompatibilities.

Finally, with the input bank/variation matching, I've included a few
different capital tone fallback qmr files.

Meanwhile, I've noticed an issue with either my Edirol USB MIDI interfaces,
or their Linux kernel modules (I've determined it's not qmidiroute):  SysEx
messages longer than 256 bytes read from MIDI input (and perhaps output,
but that's impossible to tell) are split into 256 byte chunks.
/sys/module/snd_seq_midi/parameters/input_buffer_size & output_buffer_size
show that 4096 bytes should work.  I suppose I should check the kernel
source or ask that list, but if anyone knows a solution, it would be nice
to get it straight before I have done that.

I hope you are as excited as I am about this upgrade.
Thanks,

  Lucas

[Alsamodular-devel] vsti needed

[Oliver G. <pia...@gm...>]

 Dear colleagues,
we develop software for medical applications. Urgently we are looking for a
VSTi. Since our application is server-based (LINUX) the VSTi should offer
the following characteristics:

1.) RUN ON LINUX-server
2.) RUN WITHOUT GUI. Medical experts simply do not have enough time to edit
or use software-instruments bedside. Therefore we have to prepare different
sound-configurations (16 different sounds/set, MIDI-ch 1-16), the sets will
be pre-loaded and the users shall neither see nor touch the GUI of the VSTi.
3.) real-time tweaking of different parameters (volume, filter, lfo,...) in
realtime (MIDI-CC automatisation of a few parameters)

My question is, if your modular-synth would fit the needs of our
application.

I am very thankful for your support!
Best regards
Oliver

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

At long last, here's another patch.  Everything else still seems to be
working and now I've patched a segmentation fault that happened when
time-shifting audacious.  It probably occurred under other conditions too,
but for me, audacious made it obvious.  Now, I can once again enjoy the
very useful feature of audacious to be able to skip to anywhere in a track
without playing the whole song (although, skipping SysEx should be
avoided).  If I'm not mistaken, this bug has existed for a very long time,
and is in the original, unpatched, version of qmidiroute-0.4.0 and probably
well before that.

Thanks,

  Lucas

On Thu, Nov 14, 2019 at 4:43 PM Lucas E <lul...@ho...> wrote:

> This will be the final update, I hope, for a long time.  I found 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).
>
> Thanks,
>
>   Luke
>
> On Wed, Nov 13, 2019 at 7:21 PM Lucas E <lul...@ho...> wrote:
>
>> And now another (hopefully the last I'll notice).  Drums don't have a
>> variation and a test for that value meant it was looping and making the
>> drums stutter when Drum Forward was used.
>>
>> Sorry,
>>
>>   Luke
>>
>> On Wed, Nov 13, 2019 at 5:15 PM Lucas E <lul...@ho...> wrote:
>>
>>> I'm sorry, but I found and fixed a bug already.  It involves previously
>>> forwarded channels with variations set, not getting the default variation
>>> reset, mostly because of a simple "if" statement that I've now decided to
>>> remove.  Thanks, and sorry if I wasted anyone's time.
>>>
>>> On Tue, Nov 12, 2019 at 8:25 PM Lucas E <lul...@ho...> wrote:
>>>
>>>> This is a modification involving an idea I had which matches PC# values
>>>> on input to send to other ports, PC# values, and even Roland GS variations.
>>>>
>>>> I bought a Roland D-05 and wanted to experiment with it by playing my
>>>> usual midi playlist, since it only has 1 voice (2 in split keyboard mode).
>>>> 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).  Sadly, to program the
>>>> SC-8850 with the fixed GS Variation at all times, I found it necessary to
>>>> rewrite GM Reset SysEx (F0 7E 7F 09 01 F7) as GS Reset (F0 41 10 42 12 40
>>>> 00 7F 00 41 F7), so that may make this hack much more Roland-friendly than
>>>> Yamaha XG.  I don't have any XG devices to test it with yet, though, so I'm
>>>> almost certainly unaware of the mess it causes.
>>>>
>>>> I also added a "SysEx Forward" map so that devices forwarded to can be
>>>> on equal footing with the unmatched event port. It takes no input
>>>> arguments, and just outputs all SysEx received 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.
>>>>
>>>> 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 to compare
>>>> differences in quality, since they're so similar otherwise. 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'm including a test qmidiroute mapping that plays with
>>>> that idea a bit, sending pianos PC# 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.  If nothing else, it's
>>>> fun to reverse PC# maps (0-127 in->127-0 out), or to simply
>>>> increment/decrement the output PC# minimum value & hear all the instruments
>>>> change.
>>>>
>>>> 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 (which itself was based on debian's 0.4.0
>>>> source). Both retain the Note Off map functionality too, to fix the
>>>> CM-32L/CM-64 overflow assign.
>>>>
>>>> The code may be messy and a bit too much of a hack, but it works well
>>>> enough.  I used emacs to do the edits, and to keep the indenting the same I
>>>> added many spaces (though some tabs still exist).  Anyway, I hope it's
>>>> useful to someone other than me.
>>>>
>>>> Thanks,
>>>>
>>>>   Luke
>>>>
>>>>
>>>
>>> --
>>> Protect your digital freedom and privacy, eliminate DRM, learn more at
>>> http://www.defectivebydesign.org/what_is_drm
>>> On a related note, also see Windows7SINS.org: The case against Microsoft
>>> and proprietary software
>>>
>>
>>
>> --
>> Protect your digital freedom and privacy, eliminate DRM, learn more at
>> http://www.defectivebydesign.org/what_is_drm
>> On a related note, also see Windows7SINS.org: The case against Microsoft
>> and proprietary software
>>
>

-- 
Protect your digital freedom and privacy, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
On a related note, also see Windows7SINS.org: The case against Microsoft
and proprietary software

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

This will be the final update, I hope, for a long time.  I found 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).

Thanks,

  Luke

On Wed, Nov 13, 2019 at 7:21 PM Lucas E <lul...@ho...> wrote:

> And now another (hopefully the last I'll notice).  Drums don't have a
> variation and a test for that value meant it was looping and making the
> drums stutter when Drum Forward was used.
>
> Sorry,
>
>   Luke
>
> On Wed, Nov 13, 2019 at 5:15 PM Lucas E <lul...@ho...> wrote:
>
>> I'm sorry, but I found and fixed a bug already.  It involves previously
>> forwarded channels with variations set, not getting the default variation
>> reset, mostly because of a simple "if" statement that I've now decided to
>> remove.  Thanks, and sorry if I wasted anyone's time.
>>
>> On Tue, Nov 12, 2019 at 8:25 PM Lucas E <lul...@ho...> wrote:
>>
>>> This is a modification involving an idea I had which matches PC# values
>>> on input to send to other ports, PC# values, and even Roland GS variations.
>>>
>>> I bought a Roland D-05 and wanted to experiment with it by playing my
>>> usual midi playlist, since it only has 1 voice (2 in split keyboard mode).
>>> 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).  Sadly, to program the
>>> SC-8850 with the fixed GS Variation at all times, I found it necessary to
>>> rewrite GM Reset SysEx (F0 7E 7F 09 01 F7) as GS Reset (F0 41 10 42 12 40
>>> 00 7F 00 41 F7), so that may make this hack much more Roland-friendly than
>>> Yamaha XG.  I don't have any XG devices to test it with yet, though, so I'm
>>> almost certainly unaware of the mess it causes.
>>>
>>> I also added a "SysEx Forward" map so that devices forwarded to can be
>>> on equal footing with the unmatched event port. It takes no input
>>> arguments, and just outputs all SysEx received 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.
>>>
>>> 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 to compare
>>> differences in quality, since they're so similar otherwise. 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'm including a test qmidiroute mapping that plays with
>>> that idea a bit, sending pianos PC# 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.  If nothing else, it's
>>> fun to reverse PC# maps (0-127 in->127-0 out), or to simply
>>> increment/decrement the output PC# minimum value & hear all the instruments
>>> change.
>>>
>>> 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 (which itself was based on debian's 0.4.0
>>> source). Both retain the Note Off map functionality too, to fix the
>>> CM-32L/CM-64 overflow assign.
>>>
>>> The code may be messy and a bit too much of a hack, but it works well
>>> enough.  I used emacs to do the edits, and to keep the indenting the same I
>>> added many spaces (though some tabs still exist).  Anyway, I hope it's
>>> useful to someone other than me.
>>>
>>> Thanks,
>>>
>>>   Luke
>>>
>>>
>>
>> --
>> Protect your digital freedom and privacy, eliminate DRM, learn more at
>> http://www.defectivebydesign.org/what_is_drm
>> On a related note, also see Windows7SINS.org: The case against Microsoft
>> and proprietary software
>>
>
>
> --
> Protect your digital freedom and privacy, eliminate DRM, learn more at
> http://www.defectivebydesign.org/what_is_drm
> On a related note, also see Windows7SINS.org: The case against Microsoft
> and proprietary software
>

Re: [Alsamodular-devel] QMidiRoute 0.4.0 patch adding "Program Forward", "Drum Forward", "SysEx Forward", and still "Note Off" Maps

[Lucas E <lul...@ho...>]

And now another (hopefully the last I'll notice).  Drums don't have a
variation and a test for that value meant it was looping and making the
drums stutter when Drum Forward was used.

Sorry,

  Luke

On Wed, Nov 13, 2019 at 5:15 PM Lucas E <lul...@ho...> wrote:

> I'm sorry, but I found and fixed a bug already.  It involves previously
> forwarded channels with variations set, not getting the default variation
> reset, mostly because of a simple "if" statement that I've now decided to
> remove.  Thanks, and sorry if I wasted anyone's time.
>
> On Tue, Nov 12, 2019 at 8:25 PM Lucas E <lul...@ho...> wrote:
>
>> This is a modification involving an idea I had which matches PC# values
>> on input to send to other ports, PC# values, and even Roland GS variations.
>>
>> I bought a Roland D-05 and wanted to experiment with it by playing my
>> usual midi playlist, since it only has 1 voice (2 in split keyboard mode).
>> 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).  Sadly, to program the
>> SC-8850 with the fixed GS Variation at all times, I found it necessary to
>> rewrite GM Reset SysEx (F0 7E 7F 09 01 F7) as GS Reset (F0 41 10 42 12 40
>> 00 7F 00 41 F7), so that may make this hack much more Roland-friendly than
>> Yamaha XG.  I don't have any XG devices to test it with yet, though, so I'm
>> almost certainly unaware of the mess it causes.
>>
>> I also added a "SysEx Forward" map so that devices forwarded to can be on
>> equal footing with the unmatched event port. It takes no input arguments,
>> and just outputs all SysEx received 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.
>>
>> 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 to compare
>> differences in quality, since they're so similar otherwise. 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'm including a test qmidiroute mapping that plays with
>> that idea a bit, sending pianos PC# 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.  If nothing else, it's
>> fun to reverse PC# maps (0-127 in->127-0 out), or to simply
>> increment/decrement the output PC# minimum value & hear all the instruments
>> change.
>>
>> 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 (which itself was based on debian's 0.4.0 source).
>> Both retain the Note Off map functionality too, to fix the CM-32L/CM-64
>> overflow assign.
>>
>> The code may be messy and a bit too much of a hack, but it works well
>> enough.  I used emacs to do the edits, and to keep the indenting the same I
>> added many spaces (though some tabs still exist).  Anyway, I hope it's
>> useful to someone other than me.
>>
>> Thanks,
>>
>>   Luke
>>
>>
>
> --
> Protect your digital freedom and privacy, eliminate DRM, learn more at
> http://www.defectivebydesign.org/what_is_drm
> On a related note, also see Windows7SINS.org: The case against Microsoft
> and proprietary software
>


-- 
Protect your digital freedom and privacy, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
On a related note, also see Windows7SINS.org: The case against Microsoft
and proprietary software