MIDI Volume Level Conversion

New post

J JOHN MIXSON Edited December 31, 2021 15:54

Windows 10 Finale 26

Just thought I'd share something I worked through today in case it might apply to somebody else's use of Controller #7 - Volume.

I have generally been successful in using Dynamics for controlling an instrument's volume relative to the other instruments in a score, which I like doing because it seems more authentic, having assumed it's the most common way of communicating that with players.

The timbre of some digital instruments I use suffer significantly, however, when velocity / attack is reduced by using canned Dynamics to reduce volume.

But I was also uncomfortable with, and befuddled by, a lot of the results achieved by using Controller #7 instead.

So I set out to analyse what MIDI messages were actually being sent.

I composed a chart, after a number of experimental iterations, of what I found. I've adjusted my custom text expression definitions to suit and verified their reception / function through my hardware synthesizer's editor software.

... I had intended to post the chart to this forum, but just discovered that zendesk has not made that possible.

I will say that the convoluted way that Finale sends Controller #7 values out over MIDI does not seem to apply to Controllers 91 and 93, Reverb and Chorus.

Those two transparently send values appropriate to the expression decimal definitions you create.

5 comments

Date Votes

J JOHN MIXSON Edited December 31, 2021 15:58

The odd behavior displayed when sending Volume changes via custom text expressions does not apply to sending them via the menu item Send MIDI Value which correctly translates your decimal entries 0-127 into the HEX form that devices require.

Custom volume expressions must be defined in Hexadecimal form*, although the behavior is inconsistent, and values with alpha characters cannot be used at all.

For example, when I enter 7A (decimal 122) Finale truncates it to 7. But it doesn't send a 7; it sends a B, which is the HEX equivalent of decimal 11.

The exceptions are 0 and 127, which Finale correctly translates from decimal to HEX.

MIKE HALLORAN Edited December 29, 2021 22:14

Below are the contents of the chart I had intended to attach but which zendesk would not allow.

What are the chances you tried to upload a .pdf?

It must be a .jpg. .jpeg or .png. I convert PDFs all the time using the Export function of the MacOS but there are many other easy ways to do this. I don't recall if .tiff is supported.

J JOHN MIXSON Edited December 31, 2021 16:11

Thank you, Mike. You are right to suggest it, as I didn't attempt to convert. I will do that.

Finale's Mixer is in the same wheelhouse as these custom volume text expressions because Mixer sends Controller #7 values as well.

I found that Mixer presents its own set of mis-matched transmissions. See the first chart below.

It's conceivable that there could have been a purposeful algorithm to it, such as audio non-linearity, but the resulting Hexadecimal values are linear, too. To a point...

It was only right to test these controller values in Finale 27, and the results are the same.

J JOHN MIXSON Edited December 31, 2021 16:23

I always have Human Playback set to None, so have no idea whether that matters and no reason to think it might.

I'm offering two charts below, solutions to the quandaries I've raised, for posterity, I guess.

This first one will allow me to avoid timbre changes from using Dynamics (velocity) and enable me to use the Mixer for initial & accurate volume balancing.

Later, I can embed custom volume text expressions to match and run the Faders all the way back up.

The second chart is similar to the first one, but addresses text expressions, whose idiosyncrasies are different as alluded to earlier.

I was unable send text expressions resulting in the exact values 114, 62, and 10 because...

Well, Finale just wouldn't do it.

J JOHN MIXSON Edited January 07, 2022 15:14

NOTE: It is very important to move a channel's Mixer fader all the way up to maximum when using custom volume expressions on that channel.

The results reported in the second chart above are opaque enough as it is, and otherwise, all bets are off.

My entries above have been edited this morning for clarity.

My thanks to Mike Halloran for the .png suggestion.

Please sign in to leave a comment.