CC #88 High Resolution Velocity Prefix

Bome Products
1

Hello,

I wrote a script in in Bome MIDI Translator Pro to accurately model the changes in dynamics (loudness) produced by historical pneumatic player pianos. I can assign the calculated values to note-on events, but for that I need to rescale to the range of 0-127, which is not accurate enough for me. I found out about the possibility to use high-resolution velocity by sending a velocity prefix on CC88, thereby increasing the velocity range to 128-16.383 - Is there a way of using this option in BMTP? I have the dynamic level calculated and stored in a global variable “ge” within the appropriate range, but I don’t know how to configure the outgoing message for the note-on event to take advantage of the higher resolution.
Thank you for any help, best regards, Sebastian

2

Hi, I might be able to help. So does the note on event represent the least significant byte (LSB) 0-127 and CC 88 represent the most significant byte ?

I assume you need to send CC 88 before the note-On message and then the shifted value of C88 get ORd with the note velocity.

This is pretty simple but want to confirm this is what you want before setting it up.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services: bome@sniz.biz
3

Hi Steve, thank you for responding so quickly! If I understand it correctly, the higher 7 bits of the velocity need to go into the note-on message, and the lower 7 bits need to be sent in cc88 just before the note-on event. Here are the specifications I found online:

CC #88 High Resolution Velocity Prefix (CA-031)

Source: AMEI MIDI 1.0 Board

Abstract:

Defines MIDI Continuous Controller 88 (58H) as High Resolution Velocity Prefix to the subsequent Note On / Note Off message.

Background & Purpose:

High Resolution Velocity Prefix is intended to improve Note On/Off Velocity resolution while keeping compatibility with older instruments. High Resolution Velocity Prefix is intended to be used when 7-bit Note On / Note Off velocity resolution is not enough. In conjunction with this message, 14-bit resolution can be achieved.

This message is not intended as a substitute for any future data-resolution extension of MIDI.

[CONTROLLER MESSAGE]
HIGH-RESOLUTION VELOCITY PREFIX
Bn 58 vv
vv = lower 7 bits affixed to the subsequent Note On / Note Off velocity

The velocity byte in the subsequent Note On / Note Off message represents the higher 7 bits of the velocity.

A single High Resolution Velocity Prefix message only affects the next Note On or Note Off received on the matching channel. There may be other MIDI messages in between the High Resolution Velocity Prefix message and the subsequent Note On or Note Off message. After the standard Note On or Note Off message has been
parsed, the lower 7 bits of the receiver’s 14-bit velocity register should be cleared.

In order to maintain compatibility with the Note On Running Status shortcut (9n kk 00 acts as Note Off), the smallest possible 14-bit Note On velocity shall be 0080H. The least significant bit of the upper 7-bit message is set to 1, the same as the standard softest Note On message. The largest 14-bit velocity shall be 3FFFH. Hence, the entire Note On velocity range consists of 16,256 steps. If 9n kk 00 is received, that still qualifies as a valid Note Off, and the preceding Bn 58 xx has no effect.

If the receiver does not recognize this message, it will just ignore the message and accept only higher 7 bits of the standard Note On and Note off messages.

Thanks a lot, Sebastian

4

Hi,

Give the attached a try.

We look for note-on and note-off messages by evaluating the 3 byte incoming message. If it is not a note-on or note-off we do nothing.

We use the incoming velocity qq for the MSB
We extract the LSB from the global variable ga
We allow all channels by extracting the Channel number from oo.

We send a 6 byte message for output. If qq is 0 both values will be 0

bx 58 rr 9x pp qq

Where x is the channel, rr is the MSB extracted from ga, pp is the note number and qq is the MSB velocity used from the incoming message. Allo numbers above are in hex.

(I’m not clear on whether to use the MSB or LSB of this since we are using qq as the MSB according to the spec).

If the incoming velocity is 0 (9x pp 00), then both rr and qq will be 0

CC88-Velocity.bmtp (1.4 KB)

Steve Caldwell
Bome Customer Care

Also available for paid consulting services: bome@sniz.biz
5

Hi Steve,

I just gave it a quick try. The high-res capable virtual piano software I am using does recognize the velocity correctly! I will need to make some adjustments to integrate this into my existing script, but my basic problem is solved.
Thanks a lot, this was a huge help to me!
Best regards, Sebastian

6

Yes, my guess is you need to extract the LSB from your global variable for CC88 and then use the incoming note for MSB or just simply extract the LSB and MSB from the global variable ignoring the incoming note velocity unless it is 0 (for note-off)

7

Exactly, I will probably need to take both LSB and MSB from the global variable. I guess I will just have to devide “ga” by 128 for that?

8

Hi Say you want to use the global variable ga

// Extract MSB
pp=ga>>7
// Make sure it is not out of range (in case of higher bits)
pp=pp&0x7f
// Extract LSB
qq=ga&0x7f

Now pp has MSB and qq has LSB

Steve Caldwell
Bome Customer Care

Also available for paid consulting services: bome@sniz.biz
9

Great, thank you, I will try to make this work!