Midi explanation in Hex for those asking how to edit .ini files

[Bassman]

Visit www.midi.org for the full spec but it's all in binary.

Here's an explanation in hex, as that's what's used by midibox.

Also, what I call a 'Command', Midibox refers to as the 'Status byte".

I think 'Command' makes things more understandable.

MIDI Commands in HEX

All Midi commands are higher than 7f Hex (127 decimal, 01111111 binary). They start with 80 Hex (128 decimal, 10000000 binary), which means that a command always has bit 7 set (10000000 binary)and the associated values that follow the command do not have bit 7 set (011111111 binary). This is how midi primarily distinguishes between commands and data.

You don't need to know that to edit the .ini files.

The first byte of all midi commands is divided into the command half and the midi channel half.

NOTE OFF (still in use for older gear mainly, now most devices use NOTE ON with velocity = 0 instead)

8X NN VV

8 is the command half for a NOTE OFF

X is the midi channel half - range 0-F (0-15 decimal)

NN is the NOTE NUMBER - range 00-7F (0-127 decimal)

VV is the notes VELOCITY - range 00-7f (0-127 decimal)

NOTE ON

9X NN VV

9 is the command half for a NOTE ON

X is the midi channel half - range 0-F (0-15 decimal)

NN is the NOTE NUMBER - range 00-7F (0-127 decimal)

VV is the notes VELOCITY - range 00-7f (0-127 decimal)

(VELOCITY vaue 0 (zero) is now used for NOTE OFF)

POLYPHONIC PRESSURE (some call it AFTERTOUCH)

AX NN VV

A is the command half for a POLYPHONIC AFTERTOUCH

X is the midi channel half - range 0-F (0-15 decimal)

NN is the NOTE NUMBER - range 00-7F (0-127 decimal)

VV is the AFTERTOUCH AMOUNT - range 00-7f (0-127 decimal)

CONTINUOUS CONTROLLER (CC for short)

BX CC 7F

B is the command half for a CONTINUOUS CONTROLLER

X is the midi channel half - range 0-F (0-15 decimal)

CC is the CONTROLLER NUMBER - range 00-7F (0-127 decimal)

VV is the CONTROLLER AMOUNT - range 00-7f (0-127 decimal)

PROGRAM CHANGE

CX PP

C is the command half for a PROGRAM CHANGE

X is the midi channel half - range 0-F (0-15 decimal)

PP is the PROGRAM NUMBER - range 00-7F (0-127 decimal)

CHANNEL PRESSURE (some call it AFTER-TOUCH)

DX VV

D is the command half for a CHANNEL AFTERTOUCH

X is the midi channel half - range 0-F (0-15 decimal)

VV is the AFTERTOUCH AMOUNT - range 00-7f (0-127 decimal)

Note : Thorsten comments the use of this midi command as 3 bytes.

"D. .. .. (Channel Aftertouch) Example: D0 30 7F @OnOff  (MIDIbox sends D0 30 vv)"

This might cause problems with some gear as it should be 2 bytes.

There should be no note associated with this command.

It affects all notes being held down on the same midi channel.

PITCH BEND

EX B1 B2

E is the command half for a PITCH BEND

X is the midi channel half - range 0-F (0-15 decimal)

B1 is the first half of the PITCHBEND AMOUNT - range 00-7F (0-127 decimal)

(refered to as the least significant byte)

B2 is the second half of the PITCHBEND AMOUNT - range 00-7F (0-127 decimal)

(refered to as the most significant byte)

Note: when B1 and B2 are both 40 hex (64 decimal), that is centered, no pitchbend.

                Note: Thorsten works this out for you in the firmware, so just use range 0-7F (0-127 decimal)

There are more midi commands, but this should help get you started.

bassman

[jimhenry]

Nice job Bassman! That should be added to the Wiki.

[stryd_one]

Yep, that is good doco, definitely should be on the wiki instead of here :) (Cut from here, paste to the wiki, format it up, and paste the link to the wiki back in here)

Probably worth mentioning that the 'commands' are usually referred to as the 'status byte' so that people can relate your plain-english explanation to the other technobabble they find around the net. And a link to The Brainwashing Centre at the end for those who need more: http://home.roadrunner.com/~jgglatt/tech/midispec.htm

[Bassman]

I amended, with your suggestion re: status byte. Quite right.

I would paste it to the wiki, if I could figure out how. I have it ready to paste.

Oh... there's 'technobabble' aplenty at www.midi.org.  :D

Hopefully, it will help some, I see the question often enough, maybe it'll be a few less replies for stryd, I notice he's always answering that one. Amazing how many people don't understand midi!

I also found this cool page from Univ. NSW australia.

http://www.phys.unsw.edu.au/jw/notes.html

might be useful for the wiki too?

bassman

[stryd_one]

Yah that link is nice, I like the pics especially

The wiki should be pretty easy... assuming you're already logged in (same username/pass as the forum) then you can edit any existing page such as this one http://www.midibox.org/dokuwiki/midi_specification .... Or, you can make your own URL like http://www.midibox.org/dokuwiki/simple_midi_specification and when you visit it, it'll tell you that it doesn't exist yet, and you can create it. Just, don't forget to edit some other page to link to your new one :)

[Bassman]

ok, done that, yet another syntax to figure out, standardisation is boring! ;D

I put it in About : References : Midi

http://www.midibox.org/dokuwiki/simple_midi_specification

bassman

[stryd_one]

LMAO ohhh yeh. I use a couple of firefox addons to take care of most BBCode/wiki tagging, and use the GUIs wherever possible... but the various different 'code' tags ALWAYS get me! dammit!

I added another link to it in the big midi spec page too, might save some people a very heavy read ;)

Thanks!! Doco is good!

[Per S]

NOTE OFF (not used anymore, but has to be accounted for)

8X NN VV

NOTE ON

9X NN VV

(VELOCITY vaue 0 (zero) is now used for NOTE OFF)

I would be interested to know when the Note Off Status Byte (8X) was made obsolete. I haven’t seen anything about that in various documentations but I admit I don’t have access to the very latest official Midi Specification.

I’m always using the Note Off Status Byte since to me it looks better and is easier to spot.

[stryd_one]

Err OK obviously I'm not the only one that thought that :D

[Bassman]

The NOTE OFF is still used in older gear, and you can still use it now, so it's not obselete. But when 'RUNNING STATUS' came in around '91, NOTE ON with Velocity zero started, as it allowed the same status byte to be used (or rather omitted in running status).

Running Status allows the status bit to be left out and just the note number and velocity to be sent. A different status byte would interupt running status. It allowed more data transmission to be squeezed out of the midi baud rate.

If you are just using a keyboard and a module or two, it's of no real consequence, but if you use computer software such as Cubase, Cakewalk etc, and have 8 midi ports and 20 sound modules playing away, you'll appreciate the advantage.

Access to official midi specifications is freely available at www.midi.org

bassman

[jimhenry]

NOTE OFF (not used anymore, but has to be accounted for)

8X NN VV

Maybe better to say "(many devices use NOTE ON with velocity = 0 instead of NOTE OFF)"?

I think this may point out a small issue in MIDIboxes that receive and respond to MIDI In. Do they understand that 8X NN VV and 9X NN 00 both do the same thing? I've never used the MIDI In on a MIDIbox for anything so I just don't know.  Does MIOS translate one of those to the other?  ???

For that matter, does MIOS handle running status for MIDI In or create running status on MIDI Out? I'm guessing yes, at least for handling running status on MIDI In.

(Yes I know I'm being lazy and I could go find the answers. But since I don't care about the answers at the moment let's just say I'm asking for the benefit of someone who might not have thought of the questions. If someone knows the answers off-hand that is great but otherwise just leave it for someone who needs this information to go find it.)

[Bassman]

Amendment duly noted, Jim.

Midibox does not send 80 NN VV (NOTE OFF), but if it receives it, it is converted into a NOTE ON with velocity 0.

However I see no sign of any use of 'running status' to transmit or accounting for receiving 'running status' events. I'm not sure if 'running status' bytes are merged and re-sent.

I would suggest, that users needing to use the Merge function and/or the Midi In for remote, should look in the item that is sending, to see if 'running status' can be turned off somewhere.

I think, the code looks like it should ignore midi events that do not have their status bytes first.

Just my opinion from looking through the relevant code, quickly.

Probably TK can enlighten us further!

bassman

[Per S]

Midibox does not send 80 NN VV (NOTE OFF)

The Midibox, at least the MIDIO128, does send Note Off. Here's a clip of my INI file.

##########################################
# Pin   # On Evnt # Off Evnt # Behaviour #
##########################################
    1 =  90 2F 7F   80 2F 00   @OnOff # B2  Great
    2 =  90 2E 7F   80 2E 00   @OnOff # A#2 Great
    3 =  90 2D 7F   80 2D 00   @OnOff # A2  Great

And here's the response from MIDI-OX

0000658A   9  --     90    2F    7F    1  B  2 Note On    
000065FA   9  --     80    2F    00    1  B  2 Note Off   
00007977   9  --     90    2E    7F    1  Bb 2 Note On    
000079E7   9  --     80    2E    00    1  Bb 2 Note Off   
00007C2E   9  --     90    2D    7F    1  A  2 Note On    
00007CCB   9  --     80    2D    00    1  A  2 Note Off   

MIDIO128 version 2.2b

[Bassman]

Well ok, Per S, you can get NOTE OFF to happen by editing the .ini file to deliberately send NOTE OFF.

I didn't really mean that you can't get it to happen.

However, MIDIO128 will convert incoming NOTE OFF status bytes to NOTE ON velocity 0.

So try merging your core through another core, using the Midi In Merge. You'll find your NOTE OFF have gone, they'll be NOTE ON.

Plus, if you ever want to use midi input to trigger events by using 'Forward Input to Output', and decide to use Note on/off messages, you'll find that MIDIO128, after converting incoming NOTE OFF status bytes to NOTE ON velocity 0, will not find a match in your MIDIO Presets.

The MIDIO128 .ini file clearly shows NOTE OFF (80 NN VV) as not supported for midi in.

I'm not sure it's a good idea to use NOTE OFF anymore, especially just because it looks neat when monitored. Sooner or later, there'll be trouble, mainly for those that my original post was trying to help.

But, of course, some older (and maybe more desirable) equipment may well work better with NOTE OFF being sent.

bassman

[Per S]

However, MIDIO128 will convert incoming NOTE OFF status bytes to NOTE ON velocity 0.

True

So try merging your core through another core, using the Midi In Merge. You'll find your NOTE OFF have gone, they'll be NOTE ON.

I have three cores chained with Midi Merge enabled. It looks like this:

ID00-->ID02-->ID01-->MIDI In on the PC.

Here's the INI file for ID02

#########################################
# Pin   # On Evnt # Off Evnt # Behaviour #
##########################################
    1 =  93 2F 7F   83 2F 00   @OnOff # B2  Solo
    2 =  93 2E 7F   83 2E 00   @OnOff # A#2 Solo
    3 =  93 2D 7F   83 2D 00   @OnOff # A2  Solo

The result after merging in core ID01 and sent to the PC

00047088   9  --     93    2F    7F    4  B  2 Note On      
0004712C   9  --     83    2F    00    4  B  2 Note Off     
0004756F   9  --     93    2E    7F    4  Bb 2 Note On      
00047630   9  --     83    2E    00    4  Bb 2 Note Off     
000478DC   9  --     93    2D    7F    4  A  2 Note On      
0004795E   9  --     83    2D    00    4  A  2 Note Off     

The Core Midi Merge function is happily forwarding the Note Off (8X). In my opinion this is the correct way, a merge function shouldn't change anything, it should just forward what's received.

It was not my intention to start an animated discussion but merely point out that the Note Off (8X) Status Byte is still, according to the latest MIDI Spec, a valid Status Byte, and is not (yet) obsolete.

[TK.]

MIOS decodes incoming MIDI events, so that the user application doesn't need to take care about the running status - USER_MPROC_NotifyReceivedEvent will always get the complete event. This not only simplifies the programming of a MIDI processor, but also the merging of an incoming and an internally generated MIDI stream (the user application isn't able to send a new event so long an incoming event has been forwarded completely)

Note On with velocity 0 -> Note off conversion has to be done at application side (see also this example).

With enabled MIDI merger, the discarded status byte of an incoming MIDI event which gets use of running status feature will be added to by MIOS before the event will be forwarded. This isn't an optimal solution, but some years ago I didn't see a need for this, meanwhile I would like to add such a feature to MIOS (once I find the time...). It will require a timer function which resets the running status after some time (e.g. after one second) to ensure, that a MIDI receiver sooner or later receives the running status if the MIDI cable has been disconnected/connected during runtime.

Best Regards, Thorsten.

[Bassman]

Yes you're right Per S, I was more concerned with what MIOS does with 'running status' and got mixed up. It seems that 'running status' messages are converted to 'full midi' messages by having their status bytes added on before re-sending. Thanks TK, for clearing that up.

Anyway, no-one is suggesting NOTE OFF is obsolete. It's perfectly valid.

However, if you use incoming midi to trigger events, it would be prudent not to use NOTE OFF messages for this, as most of the applications convert this to NOTE ON vel. 0, so when the app. searches for a match with NOTE OFF, it probably won't find it.

At least the situation is clear now, and there shouldn't be any trouble whatever messages are used.

bassman

[stryd_one]

However, if you use incoming midi to trigger events, it would be prudent not to use NOTE OFF messages for this, as most of the applications convert this to NOTE ON vel. 0, so when the app. searches for a match with NOTE OFF, it probably won't find it.

That's why you should do it like TK did - use an OR statement and treat both messages the same way. Software may (almost) always convert to note on vel 0, but hardware does not.

[jimhenry]

This is a most enlightening discussion!

I've looked at the code for MIDIIO128. It converts a MIDI In Note Off message to a Note On with velocity 0:

MIDIO_MIDI_Scan
	;; if note Off event has been received, convert it to Note On with velocity == 0
	movf	MIOS_PARAMETER1, W
	andlw	0xf0
	movwf	TMP2
	xorlw	0x80
	bnz	MIDIO_MIDI_Scan_NoNoteOff
MIDIO_MIDI_Scan_NoteOff
	movlw	0x90
	iorwf	MIOS_PARAMETER1, F
	clrf	MIOS_PARAMETER3
MIDIO_MIDI_Scan_NoNoteOff

Therefore it should be pointed out that in configuring the Input portion of the MIDIIO128 configuration table, NOTE OFF (0x8n) should not be used because any NOTE OFF that is received will be converted to NOTE ON with velocity 0. A NOTE OFF in the Input section of the configuration table will never be selected by MIDI Input.

You can use NOTE OFF in the Output portion of the MIDIIO128 configuration table and whatever you use will appear unaltered on the MidiBox MIDI Out Port. However, it is probably better to use NOTE ON with velocity 0 rather than NOTE OFF for consistency with the Input section and for greater efficiency if MIOS were to support running status for MIDI Out in the future. (MIOS does handle running status in the MIDI In.)

Hope I got all that right.

[Bassman]

That is exactly the way I see it, Jim. The code you found is quite self explanatory. And TK cleared up what I was suspecting in MIOS.

I thought it best to point those, who need to know how to edit their .ini files, away from using NOTE OFF and save them from any possible puzzle.

bassman

[jimhenry]

Thanks for posting warnings to this subtle trap in preparing .ini files Bassman. I only looked at MIDIIO128 but I assume the same considerations apply to .ini files for any of the official MidiBox applications that process Note messages from MIDI In, and should apply to all such applications.

How about this for the parenthetical on NOTE OFF:

NOTE OFF (NOTE ON with velocity 0 required for input configuration, preferred for output)

[Bassman]

It's possible, as all .ini files can be edited. TK made it that way for flexibilty.

Perhaps TK might nameise an amendement to the code documentation to make it clearer.

################################################################################
# The MIDI_IN and MIDI_OUT sections include all settings for the IO pins
#
################################################################################
# Syntax for a MIDI IN entry (MIDI event controls output pin):
#   <pin-number> = <byte 0> <byte 1>
#
# The maximum allowed number of output pins is 128
#
# Supported MIDI events (. stands for hex digit, vv stands for 00 or 7F)
#   9. .. (Note On)            Example: 90 30   (MIDIO128 receives 90 30 vv)
#   A. .. (Poly Aftertouch)    Example: A0 30   (MIDIO128 receives A0 30 vv)
#   B. .. (Controller)         Example: B0 07   (MIDIO128 receives B0 07 vv)
#   C. .. (Program Change)     Example: C0 30   (MIDIbox receives C0 30) 
#   D. .. (Channel Aftertouch) Example: D0 30   (MIDIbox receives D0 30)
#   E. .. (Pitch Bender)       Example: E0 7F   (MIDIbox receives E0 7F vv)
#
# - On 2-byte events (C. and D.), the output pins just toggle (0->1 or 1->0)
################################################################################
# Syntax for a MIDI OUT entry (input pin triggers MIDI event):
#   <pin-number> = <ON byte 0> <ON byte 1> <ON byte2> <OFF byte 0> <OFF byte 1> <OFF byte2> 
#
# The maximum allowed number of input pins is 128
#
# Supported MIDI events
#   (Note On)            Example: 90 30 7F 90 30 00 @OnOff (ON: send 90 30 7F, OFF: send 90 30 00)
#   (Poly Aftertouch)    Example: A0 30 7F A0 30 00 @OnOff (ON: send A0 30 7F, OFF: send A0 30 00)
#   (Controller)         Example: B0 07 7F B0 07 00 @OnOff (ON: send B0 07 7F, OFF: send B0 07 00)
#   (Program Change)     Example: C0 01 00 FF 00 00 @OnOff (ON: send C0 01,    OFF: send nothing!)
#   (Channel Aftertouch) Example: D0 40 00 FF 00 00 @OnOff (ON: send D0 40,    OFF: send nothing!)
#   (Pitch Bender)       Example: E0 30 30 E0 60 60 @OnOff (ON: send E0 30 30, OFF: send E0 60 60)
#
# Also valid:
#   (Note On/Off)        Example: 90 30 7F 80 30 00 @OnOff (ON: send 90 30 7F, OFF: send 80 30 00)
#   (Controller Fun)     Example: B0 10 40 B0 11 40 @OnOff (ON: send B0 10 40, OFF: send B0 11 40)
#
# - If byte0 is FF, the event will not be sent
#
# Supported button behaviours (see MIDIbox tutorial):
#    @OnOff
#    @OnOnly
#    @Toggle
#
################################################################################

This part maybe could read something like;

# Also valid, but not recomended as Note Off is NOT a supported Midi In Event:
#   (Note On/Off)        Example: 90 30 7F 80 30 00 @OnOff (ON: send 90 30 7F, OFF: send 80 30 00)

Either way, the information IS there, though perhaps not conspicious by it's absence, Note Off is not supported for Midi In.

bassman

[jimhenry]

I'm surprised that the absence of NOTE OFF in the MIDI IN entries doesn't cause more questions. Maybe the MIDI IN isn't used so much. Or maybe I just lead a sheltered existence.  ;)

I agree with you Bassman, a bit more in the comments would seem like a good idea. Perhaps like this:

# Supported MIDI events (. stands for hex digit, vv stands for 00 or 7F)
#   9. .. (Note On)            Example: 90 30   (MIDIO128 receives 90 30 vv)
#   A. .. (Poly Aftertouch)    Example: A0 30   (MIDIO128 receives A0 30 vv)
#   B. .. (Controller)         Example: B0 07   (MIDIO128 receives B0 07 vv)
#   C. .. (Program Change)     Example: C0 30   (MIDIbox receives C0 30) 
#   D. .. (Channel Aftertouch) Example: D0 30   (MIDIbox receives D0 30)
#   E. .. (Pitch Bender)       Example: E0 7F   (MIDIbox receives E0 7F vv)
#
# - 8. .. (Note Off) is translated to 9. .. 00 by the application
#                         Example: 90 30  (MIDIO128 receives 80 30 vv, DOUT pin is turned off)
# - On 2-byte events (C. and D.), the output pins just toggle (0->1 or 1->0)

It seems that for 3-byte events--9 Note On/Off, A Poly Aftertouch, B Controller, and E Pitch Bender--vv == 0 turns the output off (high) and vv > 0 turns the output on (low). That should be put in the comments as well.

(I think the MIDI specs say that vv < 64 is off and vv >= 64 is on, but vv > 0 for on probably makes more sense for typical MidiBox uses as a Note On of any positive velocity should turn on the output.)

While we are at it, should the comment block explaining the DOUT section be moved down to be just above [MIDI_OUT]?

[Bassman]

Probably this thread will have TK thinking about adding a few more notes by now. Tk is the name and it's up to him to make alterations even in the documentation, though we all know he's busy, but nonetheless, we are not at liberty to make changes.

But maybe between us we can do a full document for the Wiki all about using Midi In to trigger events. I suspect it's not used much, but it has many useful aspects to it, especially when there are more than 1 core and one of them is mainly used for a master controller, as I expect you do with organ setups.

It gets a little confusing with 3 byte events other than NOTE ON Vel. 0 or >0.

For controllers, mostly v=0 would be off, but not all of them.

Poly Aftertouch seems ok with v=0 being off.

Pitchbend would not be right for v=0 to be off. Even though it is a 3 byte event, it differs from the others in that it is EX vv1 vv2, a 14bit data send. The documentation shows it as E0 7f vv, but that is to make the editor just use a 0-7f value to keep things constant through out the app., though it is converted into a 14 bit message in the app.

	;; sending three bytes (7bit converted to 14bit)MIDI_EVNT_Send_Ex	; Pitch Bend
	movff	MIDI_EVNT0, WREG
	call	MIOS_MIDI_TxBufferPut

	SET_BSR	MIDI_EVNT0
	movlw	0x00
	BRA_IFCLR MIDI_EVNT_VALUE, 6, BANKED, MIDI_EVNT_Send_ExLow
	rlf	MIDI_EVNT_VALUE, W, BANKED
	andlw	0x7e
MIDI_EVNT_Send_ExLow
	call	MIOS_MIDI_TxBufferPut
	movff	MIDI_EVNT_VALUE, WREG
	andlw	0x7f
	call	MIOS_MIDI_TxBufferPut
	rgoto	MIDI_EVNT_Send_End

So vv1=64 & vv2=64 would be considered off (ie. center). I don't know if this one is worth using for midi in control to the DOUT, it would only go off when you pitch bent fully down, (well...it might have a use).

The DOUT is just a switch and will turn off at 0 and on at anything >0 (I'm not sure here)? So maybe it's only good for midi events where that is appropriate.

Having said that, there's no reason why the inventive use of midi to get what one wants, needs to be ristricted.

I don't see much discussion about it, seems like some experimenting, and then a document, might encourage people to make more us of it?

Lastly, re: the DOUT comments, they're not in the .ini file (at least not mine) so I'm not sure about that.

Also what about the relay.ini file? And the midio_presets.inc, have you tried editing this?

bassman

[stryd_one]

Probably this thread will have TK thinking about adding a few more notes by now. Tk is the name and it's up to him to make alterations even in the documentation, though we all know he's busy, but nonetheless, we are not at liberty to make changes.

Well that's not entirely true. Those of us with 'Frequent Writer' or 'Programmer' ,as well as mods and admins, do have write access to the repository... of course any changes should be thoroughly tested and crosschecked with other experienced programmers, and if it's something major, you should definitely crosscheck it with TK before commiting... but the point is, if we want to, we can do it.

I think it's best to do all the work, provide good documentation of the changes, suggest it in the forum, and that way TK can make a quick decision, and we can do the upload. This way, we get the boss' "OK", and it takes him no time.

As for handling 8n status bytes in the ini files, I think that a preferable solution to lots of documentation is to enhance the ini file parser to convert them to 9n ** 00.