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)
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
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]?
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
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.
JimHenry:
Close, but not quite.
an on/off control handled by 0-127 would be
<64=OFF, >63=ON. It makes more sense if you see the values in binary. The most significant bit is the On/OFF switch.
So any value of 64 or above is ON.
To center a 7 bit value, such as balance or Pan, the valid range is 1 to 127, with 64 as center. Input values of zero should be converted to 1. (ref www.midi.org/techspecs/rp36.php)
To center a 14 bit value, you don’t set both bytes to 64, just the most significant one (coarse). So Coarse to 64, fine to 0 for center position.
LyleHaze
LyleHaze:
Are you saying that values < 64 are OFF is how things should work according to the MIDI Spec, which I agree with, or how MIDIO128 does work now, which is not what I see by inspecting the code but I could be wrong?
Stryd,
I don’t personally think that’s the best solution. Some old midi gear only works with 8n status, so it needs to be there for those.
LyleHaze,
[tt]an on/off control handled by 0-127 would be <64=OFF, >63=ON.[/tt]
This is ok for controllers that are strictly ON/Off such as Sustain Pedal. Even so, not all manufacturers have adhered to that, there are some that have implemented as 0=off >0=ON.
Other controllers have a range 0-127 (0-7f H) and some like pan would be centered at 64 (40 H).
There’s no general rule here.
Pitchbend has been implemented differently too. Some manufacturers have used 64 & 0 (40 & 00 H) for center and sent true 14 bit messages, many have 64 & 64 (40 & 40 H) as center and increment/decrement both bytes equally.
According to midi.org ;
[tt]Pitch Wheel Change. 0mmmmmmm This message is sent to indicate a change in the pitch wheel. The pitch wheel is measured by a fourteen bit value. Center (no pitch change) is 2000H. Sensitivity is a function of the transmitter. (llllll) are the least significant 7 bits. (mmmmmm) are the most significant 7 bits. [/tt].
They claim 2000H as center.
They all seem to work though. Try running various brands pitchbends through midiox and you’ll see.
Then, there’s what midibox actually does with midi.
If we’re looking an overall ‘rule’, we’re not going to find it.
Just because midi.org set themselves up as the ‘midi standard’ creators, doesn’t mean everyone follows that. Some think their way is best and want to be rebels.
Sound familiar? ;)
bassman
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.
I think Stryd has a good idea here. With regard to the handling of MIDI In to a MidiBox we have established that at least MIDIO128 will translate 8n ** ** to 9n ** 00. Thus, as it stands, one needs to use 9n rather than 8n in the .ini configuration table because MIDIO128 will use 9n to search the table when it receives an 8n status byte. If the tools that make a SysEx file from the text .ini file parsed 8n and 9n to produce the same result in the table that is actually loaded on the MidiBox, then there is no need to “paper” this issue with comments. It doesn’t affect what MIDI Messages MIDIO128 will recognize. Sending either 8n ** ** or 9n ** 00 to MIDIO128 will turn off the selected DOUT pin.
There is an underlying subtlety of the MIDI standard worth mentioning. The Note On/Note Off pair 9n/8n is the only pair of MIDI messages where on and off are done with two different status messages. MIDIO128 makes the assumption that MIDI Inputs for on/off control can be configured with just the first two bytes of the MIDI message. The third byte of the message is handled algorithmically. Thus, MIDIO128 does not provide any way to explicitly configure a DOUT pin as being controlled by 9n for note on and 8n for note off.
Yes I see that, but this is all ‘under the circumstances’ which, to me is not the best solution. As it stands, parsing all the midi in status bytes to be 9n, in case an editor has made them 8n, will work, obviously.
But…we’re giving up a whole midi command with 128 numbers!
Maybe 8n status should be implemented properly, rather than being ‘not supported’. It’s original function may be lost in the ‘forgotten world since synths began’, but it is very useful. It, quite rightly provides a velocity, or sensitvity, for releasing a note. Many instruments are affected by this, Piano, reeds, percussion, vibraphone and anything with a damper etc. Even organs can have a nice ‘chuff’ effect when simulating the wind in the pipes being shut off.
Now this may not be of interest to many in this beat box era, (which is ok too), but even from a ‘techy’ point of view, that’s another 128 numbers we can use for control. Isn’t that useful?
Suppose you had a vintage keyboard that only sent 8n, you could have DOUT pins that ONLY that keyboard could control, if you didn’t have the conversion to 9n. Or one core could send 8n and another 9n. They would both work perfectly as notes, but you would have some more control specific to one or the other.
Just because everyone’s doing the 9n thing now, doesn’t mean we can’t make use of both.
bassman
Maybe 8n status should be implemented properly, rather than being ‘not supported’.
Of course that’s the preferable path to take if it’s possible 
Well, I may be wrong, but it seems like only a small amendment is needed.
This is the MIDIO128 code that does the converting. It’s the first part of the midi scan within the MIDIO_MIDI_NotifyReceivedEvent routine, after a check is done for an All Notes Off CC.
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
It then goes on to check
;; set TMP5[0] if the second byte shouldn't be checked; this is the
;; case for:
;; o Channel Pressure
;; o Pitch Bend
and
;; set TMP5[1] if the value is located in second, and not in third byte
;; this is the case for:
;; o Program Change
;; o Channel Pressure
and
;; if program change branch depending on MIDIO_CFG0_ALT_PROGCHNG
then goes on to scan the DOUTs and then prepare a DIN Event and then Send it. It seems that if the start of the MIDIO_MIDI_Scan looked like this instead, then the conversion would not be done, and everything else would appear to be ok.
MIDIO_MIDI_Scan
;These lines need to stay
movf MIOS_PARAMETER1, W
andlw 0xf0
movwf TMP2
MIDIO_MIDI_Scan_NoNoteOff
But it seems too simple, so I’m probably wrong.
bassman
JimHenry:
I was referring to my understanding of the MIDI spec. I have no knowledge of the MIDIO128 or how it handles things. Sorry if I was off-topic or misleading.
Regarding options for note-on and note-off, I’ll suggest a programmers response:
The sender may use either, the receiver must deal properly with both.
For my own projects, as MIDI input is first handled, any note-on with a velocity of zero immediately gets bit 4 of the status byte reset. This makes life a lot easier for the code that follows.
But we each get to do it our own way, as long as every receiver can handle both, every sender can do as they wish.
I can’t imagine a pitch bend value that shifts both seven bit values separately. There would be only seven bits of resolution that way, but then, I can’t rule out that some idiot has done it that way.
True, the MMA is just the governing body that writes the MIDI standard, we are under no obligation to follow their rules, as long as we have no interest in calling our products “MIDI”. I’ll continue to follow their rules.
Have Fun,
LyleHaze
The sender may use either, the receiver must deal properly with both.
That seems quite right.
For my own projects, as MIDI input is first handled, any note-on with a velocity of zero immediately gets bit 4 of the status byte reset. This makes life a lot easier for the code that follows.
Yeah, converting them to 8n NOTE OFF events has it’s advantages.
I can’t imagine a pitch bend value that shifts both seven bit values separately. There would be only seven bits of resolution that way, but then, I can’t rule out that some idiot has done it that way.
I know, you’re quite right, but when you have the chance, try monitoring the pitch bend events from different manufacturers. It’s scary, (especially the ‘big guys’).
True, the MMA is just the governing body that writes the MIDI standard, we are under no obligation to follow their rules, as long as we have no interest in calling our products “MIDI”. I’ll continue to follow their rules.
Well, of course, but there are definately (though only small) differences in implementations. Especially between Yamaha and Roland who seem to want to compete for ‘leadership’ in the MIDI.org
bassman