90 - is the MIDI code that defines the call to "Note On"
it's not my whim - but the construction rules/syntax if you want from MIDI!
and Can I see from judging by your screenshot, you have the same reaction of KM to send Sysex - which you considered the same MIDI monitor app.
therefore - this is not my local problem! and the global one is the culprit - KM
KM is sending, and MIDI Monitor is receiving, the entire packet.
If you look at MIDI Monitor:
...the first line shows the "wrapper", the starting F0 00 00 66 10 12 end the final F7 (EOX). So the command to be interpreted is 90 64 7F.
I'm no MIDI guru (and have just seen I'm arguing with @tiffle -- believe them before me!), just playing around with MIDI Monitor, but 90 appears to be "note on, channel 1" (89 is "note off, channel 10" and 91 is "note on, channel 2", so that seems reasonable). 64 is the actual note, E6 (again, as a sanity check, 63 is D#6 and 65 is F6). It's 7F that's the problem.
Go to the documentation for whatever and review the codes you should send -- that's where the problem is.
1 Like
I know all this... and the same penultimate byte 7F - value of velocity as 127 (max note-on sound). there is no mistake ... you are wrong ...
especially - MIDI monitor only reads transfer information without embellishment or transformation... my other programs - react the same way to this output message - single note what have to sent to Loud Technologies / Mackie $6 bytes with Sysex start: F0
00 00 66 10 12
only logic pro sequencer is intercepted! although last sysex part is not intended for this app:
90 64 7F
but work properly
next coda or EOX: F7 - losted without header Sysex F0
Sysex tutorial
Learn the rules for building a MIDI Sysex. they are not complicated like 2+2=4:
head part F0 - is inseparable from EOX - F7 and includes assignments - manufacturer's name ID & device model ID: 00 00 66 10;
further command "send/transmit": 12 and message argument - 90 64 7F
Then we're both wrong -- MIDI Monitor is showing that KM is atomically sending the packet as instructed (or do you think Monitor pulled that trailing F7 out of its magic hat?).
But I might have a solution (hopefully @peternlewis has an explanation!) for you. After some playing around, try without including the EOX in the raw packet:
...which MIDI Monitor shows as:
@peternlewis -- that behaviour feels a little odd to me (although I know next to nothing about MIDI). If the velocity value is omitted then the EOX is required in KM's "raw packet" field, if velocity is included the EOX must be omitted? Rather confusing for a newb such as myself! Or is this an interpretation, rather than an output, issue?
People are being rude in this thread so I will be closing it.
If people want to start another thread on the topic, they will need to commit to being civil in it.
As I have said, Keyboard Maestro coverts the text in to bytes and sends the bytes as a single packet with a single API call. What happens after that, I have no clue. Whatever is to blame, however it is interpreted or misinterpreted, Keyboard Maestro has no ability to change.
If you want different results from the action, you will need to use different bytes in the raw packet.
2 Likes