Transforms using Raw midi

How does MTP or BB assure that the well-defined midi message length only matches the specified byte criteria within the Translator when RAW messages processing is desired?   Does it matter?

Does MTP or BB  "look up" the correct midi message length for any given message before for any midi message is submitted to a raw midi Transform?

For example:
Where incoming midi message is two bytes (oo pp).  Will the message every be submitted to a raw Transform that is testing/expecting against a three byte raw midi message such as:   oo pp qq?

OR

Where incoming midi message is three byte (oo pp qq).  Will the message every be submitted to a Transform that is testing/expecting against a raw two byte midi message such as:   oo pp ?

OR is that up to the eyes on glass and gray matter behind the keyboard?
Thank you.

Curious.  Dan

I\'m not entirely sure, but I think, if bit 8 of the byte is set (status byte), it sets that as the start of message. It will then interpret the remaining bytes until the next status byte (bit 8 set) looking for a match.

For instance if I search for C0 00 C0 00 C0 00 (three program 0 changes in a row), it will not find them but it will you send the same thing looking for only C0 00, it will find it 3 times.

Consequently for System Exclusive messages, the byte count has to be a match (exact number of bytes).

Now if you have patterns in translators as follows:

oo

oo pp

oo pp qq

And you send F8 (timing clock) 3 times. It will look like this:

1: IN   0.0  MIDI F8,  oo=0xF8

2: IN   0.0  MIDI F8,  oo=0xF8

3: IN   0.1  MIDI F8 F8,  oo=0xF8 pp=0xF8

4: IN   0.0  MIDI F8,  oo=0xF8

5: IN   0.2  MIDI F8 F8 F8,  oo=0xF8 pp=0xF8 qq=0xF8

 

If you reverse the order of the translators

oo pp qq

oo pp

oo

It will look like this on the first F8

1: IN   0.2  MIDI F8,  oo=0xF8

On the second F8

2: IN   0.1  MIDI F8 F8,  oo=0xF8 pp=0xF8

3: IN   0.2  MIDI F8,  oo=0xF8

On the third

4: IN   0.0  MIDI F8 F8 F8,  oo=0xF8 pp=0xF8 qq=0xF8

5: IN   0.2  MIDI F8,  oo=0xF8

My suggestion is you do what I did and experiment to make sure you get it right.

Also, if you want translators further down not to process after an eariler one gets a match use the \"Stop processing\" option on the translator to be safe.

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

 

 

 

 

 

 

 

Thank you, that clears it up for me. The Most Significant Bit signals a start of message delimiter, The length of message is then bounded between the next MSbit. Exception as you stated is SYSEX. Thanks again.

It is possible that MT Pro also evaluates the status byte to see how many bytes follow, but I’m not 100% sure. For Instance 8x, 9x, Bx and Ex would be 2 more bytes, Cx would be 1 more byte. F7 or F8 would be 0 more bytes.