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

[lylehaze]

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

[jimhenry]

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?

[Bassman]

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

[jimhenry]

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.

[Bassman]

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

[stryd_one]

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 :)

[Bassman]

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

[lylehaze]

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

[Bassman]

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