Volume adjustment is bugged

Please let our ADS show!

This sites offers only FREE software and it's supported by a few advertisement boxes (no intrusive popups).
Please:

  • disable your AdBlocker by adding CoolSoft website to whitelist
  • give the proper cookie consent
  • enable JavaScript for this website

This seconds wait is to let you update your browser configuration...

Ok, I've done the required changes... now show me your content!
!!! Please enable JavaScript !!!

Pages

Posts: 3
Joined: July 6, 2022 - 05:44
Volume adjustment is bugged

The volume adjustment feature seems to be adjusting more than just note-on commands; other commands are also being adjusted, including note-off, control change, and pitch bend. It appears to be changing the second data byte (that's the third byte if you include the status byte) of every three-byte command.

The obvious effects of this are greatly reduced volume (due to CC#7 (Volume) and CC#11 (Expression) being too low), instruments being panned more to the left (due to Pan (CC#10) being too low), and instruments being flat and possibly out of tune (due to pitch bend being too low).

For reference, the status byte of a note-on command has 9 as the high nibble and the channel number (starting at 0) as the low nibble, so note-on status bytes range from 90 to 9F (in hexadecimal).

I don't know how much you know about MIDI, so in case you're unaware, here are some facts that you should know:

  • A note-on command with zero velocity is actually treated as a note-off. Because of this, if a note-on command's velocity is not initially zero, then if adjustment would change it to zero, it should be set to 1 instead. Also, zero-velocity note-on commands should not be adjusted. (This is true only of MIDI 1.0; the recent MIDI 2.0 does not have this quirk.)
  • Typically, velocity is proportional to the square of the volume, not the volume itself. In other words, if the note's velocity is multiplied by x, then the volume of that note is multiplied by x times x. If you want volume response to be linear, then multiply the velocity by the square root of the volume (assuming the max volume is 1). So, for example, if you want a note to play at half volume, then instead of multiplying its velocity by 0.5, multiply it by the square root of 0.5 (about 0.71) instead. (This volume response curve is also usually true for CC#7 (Volume) and CC#11 (Expression).)
Posts: 1972
Joined: March 25, 2012 - 01:19
Re: Volume adjustment is bugged

Thanks for the detailed explanation, very clear.

Yarn366 wrote:
other commands are also being adjusted, including note-off, control change, and pitch bend. It appears to be changing the second data byte (that's the third byte if you include the status byte) of every three-byte command

Current implementation patches only NoteON messages with Vel>0; NoteONs with Vel=0 are managed as NoteOFFs (as you wrote) and pass unchanged.
Only messages with the first byte like 0x90-->0x9F are patched, no other one (no control changes, no pitch bends).

Yarn366 wrote:
The obvious effects of this are greatly reduced volume (due to CC#7 (Volume) and CC#11 (Expression) being too low), instruments being panned more to the left (due to Pan (CC#10) being too low), and instruments being flat and possibly out of tune (due to pitch bend being too low).

None of these messages are patched by the volume feature... 🤔
The pass untouched and it's up to the final synth device to manage them.
MidiMapper only applies "Windows device volume" (the one set sending MODM_SETVOLUME windows messages to the MIDI driver).

Yarn366 wrote:
A note-on command with zero velocity is actually treated as a note-off. Because of this, if a note-on command's velocity is not initially zero, then if adjustment would change it to zero, it should be set to 1 instead

You're right, this is something I haven't thought about; it could happen that, due to rounding, a legit NoteON message velocity could be rounded to 0 and make it behave like an unexpected NoteOFF message.
Will fix it 👍

Just one doubt: what should happen when volume is set to 0? With this new "algorithm" all NoteONs will have a velocity to 1... is it good or not?
This could produce an unexpected output sound, since I've set volume to 0, so I'd expect no output at all...
Shall I treat Vol==0 as a special case and force all NoteON velocities to 0 in that case?

Yarn366 wrote:
If you want volume response to be linear, then multiply the velocity by the square root of the volume

AFAIK volume potentiometers being used on audio mixers and amplifiers are logarithmics (instead of the default linear ones), so I've ever thought that volume is a logarithmic entity.
After a few reading I've seen that the most common way to measure perceived audio level is RMS; so ok, let's go for the square root, will add it 😉.

Yarn366 wrote:
This volume response curve is also usually true for CC#7 (Volume) and CC#11 (Expression).

These messages will pass untouched through the MidiMapper, and it's up to the final synth device to manage them.

Posts: 3
Joined: July 6, 2022 - 05:44
Re: Volume adjustment is bugged

To be clear, I am using MIDIMapper 2.1.0, the only released version (as of now) that implements this feature. When you described the current behavior, were you referring to 2.1.0 or a more recent development version?

coolsoft wrote:
Just one doubt: what should happen when volume is set to 0? With this new "algorithm" all NoteONs will have a velocity to 1... is it good or not?
This could produce an unexpected output sound, since I've set volume to 0, so I'd expect no output at all...
Shall I treat Vol==0 as a special case and force all NoteON velocities to 0 in that case?

In that case, I think it's better to just drop note-ons (after checking for zero velocity, of course!).

coolsoft wrote:
Yarn366 wrote:
    If you want volume response to be linear, then multiply the velocity by the square root of the volume

AFAIK volume potentiometers being used on audio mixers and amplifiers are logarithmics (instead of the default linear ones), so I've ever thought that volume is a logarithmic entity.
After a few reading I've seen that the most common way to measure perceived audio level is RMS; so ok, let's go for the square root, will add it 😉.

Yes, audio levels are normally represented logarithmically. However, computers normally store audio as linear amplitude values, which is the measurement that I was using.

The square-root thing that I recommended isn't derived from how humans perceive sound level, but rather the quadratic volume curve that MIDI synthesizers typically use to respond to velocity and the Volume and Expression controllers. If I'm correct in assuming the response to MODM_SETVOLUME is linear (so that half the max value means half volume), then the squaring done by that quadratic curve must be compensated for. The way to do that is by applying the inverse operation: square root.

(By the way, I wrote that statement because it appears to be widely believed that the normal MIDI volume response curve is linear; it isn't.)

Posts: 1972
Joined: March 25, 2012 - 01:19
Re: Volume adjustment is bugged
Yarn366 wrote:
When you described the current behavior, were you referring to 2.1.0 or a more recent development version?

Yes, I was referring to 2.1.0; it only patches NoteON messages with velocity > 0.

Yarn366 wrote:
In that case, I think it's better to just drop note-ons (after checking for zero velocity, of course!).

This was my first thought, but I wonder what will happen on synths that show "MIDI activity" (like VirtualMIDISynth does) by blinking something when a NoteON comes in?
Dropping NoteON messages will cause the activity indicator to lose al lot (if not all) of the messages, so its blinking rate will lower (or stop).
Even worse, if the synth device considers NoteON+Vel=0 messages as NoteOFF messages (like VMS does), it won't blink at all... such an hard decision 😁

Yarn366 wrote:
By the way, I wrote that statement because it appears to be widely believed that the normal MIDI volume response curve is linear; it isn't.

Yes, I agree and I'll add it 👍

Posts: 3
Joined: July 6, 2022 - 05:44
Re: Volume adjustment is bugged

What program did you use to test the volume adjustment? If it's free and still available, I'd like to try it and see whether I get the behavior that you describe. (This, of course, assumes that you actually did test it yourself.)

coolsoft wrote:
This was my first thought, but I wonder what will happen on synths that show "MIDI activity" (like VirtualMIDISynth does) by blinking something when a NoteON comes in?
Dropping NoteON messages will cause the activity indicator to lose al lot (if not all) of the messages, so its blinking rate will lower (or stop).
Even worse, if the synth device considers NoteON+Vel=0 messages as NoteOFF messages (like VMS does), it won't blink at all... such an hard decision 😁

An alternative is to change the volume controllers instead. This way, if MODM_SETVOLUME is set to zero, then it's still possible to send true note-on commands without the notes actually sounding. Also, it allows sustained notes to have their volume changed while they're sounding. Then there are the less obvious benefits, like avoiding changing an instrument's timbre due to lowering its note velocities (yes, a note's velocity actually can affect more than loudness).

The main downside to this approach is that it becomes necessary to watch for commands (mainly Sysex) that may reset the volume controllers. If you're interested, I can tell you what these commands are (at least the ones I know of) as well as some other caveats.

Posts: 1972
Joined: March 25, 2012 - 01:19
Re: Volume adjustment is bugged
Yarn366 wrote:
What program did you use to test the volume adjustment? If it's free and still available, I'd like to try it and see whether I get the behavior that you describe. (This, of course, assumes that you actually did test it yourself.)

It all started in this thread about the old game Road Rash.
That game uses the MODM_SETVOLUME to control the volume of background music.

Yarn366 wrote:
The main downside to this approach is that it becomes necessary to watch for commands (mainly Sysex) that may reset the volume controllers. If you're interested, I can tell you what these commands are (at least the ones I know of) as well as some other caveats.

This is really interesting, but patching SysEx messages is like opening a "can of worms": you know where you started, but don't know where you'll end 😀

And, also, I consider MODM_SETVOLUME as something strictly "Windows related" and "old school".
I suppose no seriuos and modern DAW/MIDI player should rely on it but, instead, directly use volume controllers.

I think that patching notes velocites, with the improved algorithm you've suggested, should be enough for those softwares that still use MODM_SETVOLUME message.

Posts: 129
Joined: September 25, 2013 - 16:38
Re: Volume adjustment is bugged

Hi Claudio,

Unfortunately OP is right. I failed to test this new feature properly since I focused only on Note On volume/velocity at that time. Your implementation currently really changes the 3rd byte of any kind of Midi messages.

I have made a demonstration video about the problem. As you can see and hear in the video midiOutSetVolume also changes CC#10 Pan (among others). I also extended the test program so besides Note On/Off messages you can test any kind of controller messages.

https://youtu.be/ayn-iTyFPrE

Attachments (Only registered users)
MidiOutSetVolumeCheck.zip
Posts: 1972
Joined: March 25, 2012 - 01:19
Re: Volume adjustment is bugged

@falcosoft: I feel so... stupid.
Yes, it was my fault, and it was such a newbie fault: an error on binary comparison when testing for NoteON messages.

Wrong code:

if (val & 0x90) != 0x00 {...

Correct code:

if (val & 0xF0) == 0x90 {...

I don't know how I was able to write that mess; and your test program immediately turned the light on 😉.
(I've also checked for the same mistake in VMS but there's no issue there... luckily these silly mistakes (should) happen only once in a lifetime).

@Yarn366: you were right from the very beginning. I'm so sorry, should have investigated deeply 😥.

I've also implemented the volume correction you've suggested and it now works much more better than before.
I've tested it with @falcosoft test program and now the volume scale is "usable" from min to max.

Attached here is version 2.1.1-beta1, waiting for your tests.

UPDATE: version 2.1.1 has been released, no changes from this beta.

Posts: 129
Joined: September 25, 2013 - 16:38
Re: Volume adjustment is bugged

Hi,

It seems it works properly now :)

Posts: 1972
Joined: March 25, 2012 - 01:19
Re: Volume adjustment is bugged

Ok, thanks.
Just released version 2.1.1 with the fix.

@Yarn366, @falcosoft: thank you both for the help 😉

Pages