fbpx
Skip to main content

MIDI Forum

Differentiating Run...
 
Notifications
Clear all

Differentiating Running Status and Control Changes Messages

3 Posts
3 Users
0 Reactions
18.4 K Views
Jose Luis
Posts: 2
Active Member
Topic starter
 

I'm reading from MIDI File (created for unknown somebody).

Reading Specification https://www.midi.org/specifications/item/table-3-control-change-messages-data-bytes-2

The Format is:
Delta_Time (VLQ) + Two Bytes (JJ - KK) where JJ is the Control Number and KK 00-7F.

But, Using Running Status

The Format is:

Delta_Time (VLQ) + XX + YY [+ ZZ], XX is the Status Byte, YY is the First Data Byte if the MIDI Event has two Bytes, ZZ is the second Data Byte.
If There is a Running Status... Then can be.

Delta_Time (VLQ) + XX + YY [+ ZZ] + Delta_Time (VLQ) + PP + QQ.

Where Running Status is has the information in Two Bytes PP and QQ...

As you can see the Format are equals!

My Question is How determinate when is Running Status and When is Control Change Messages?

The Control Messages doesn't follow to MIDI Event (determined by Status Byte)?

 
Posted : 15/10/2017 4:16 pm
Eddie Lotter
Posts: 295
Reputable Member
 

As you can see the Format are equals!

No, they're different.

Without running status it would be:
Delta_Time (VLQ) + XX + YY [+ ZZ] + Delta_Time (VLQ) + XX + PP [+ QQ].

Cheers
Eddie

 
Posted : 15/10/2017 5:02 pm
Geoff
Posts: 1039
Noble Member
 

What?

Both the above seem somewhat mixed up.

First of all, the original question is strange as there is no point in 'differentiating' between a Control message and Running Status as a control message COULD well be running status anyway. The application of certain controllers could well be done incrementally over a number of midi events:

For example, the following sequence:

Note On
Adjust Pan
Adjust Pan
Adjust Pan
Note Off

Where the second and third Pan Adjust could be Running Status.

In this example, the Note OFF could NOT be running status (as it might have been, using Note On with zero volume) as the immed previous command uses a different status byte (Bx as opposed to 9x).

Yes, I agree, running status is usually used for successive notes on the same channel, but I believe that the pan example would still be possible.

The first byte (following the Delta Time variable length number) is normally the Status (or command) byte, and this value is greater than &H7F (hex). This value is specific to this byte. The first part of the byte (in Hex) signifies the command, i.e. 9 is Note On, B is control Change, etc) and the second part (0 to F) is the Channel Number.

Following byte(s) are irregular depending on the Command number, but they will be LESS than &H80.

To support Running Status, the processing software should always, when detecting the byte greater than &H7F, remember or store this value before implementing it. Then, when processing any subsequent command, if this new command has its own Status/Command byte, it should replace the stored data with the new one, if the new command does NOT have such a byte (as it's running status) then it should re-use the previously remembered byte.

Geoff

 
Posted : 16/10/2017 9:30 am
Share: