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)?
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)?
Accepted Answer
0
Undo
Votes
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
Accepted Answer
0
Undo
Votes
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
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
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
- Page :
- 1
There are no replies made for this post yet.
