Why you're still insisting on using that malformed SysEx dump is beyond me...
I do not insist, and gave additional examples of how to simplify this task of sending down to 0x90 0x64 0xF7.
But you must admit that KM and SendMIDI are work with problematic Sysex, but the results are different...
If the message is simplified to 0x90 0x64 0xF7, then SendMIDI will deliver it to the desired recipient, but KM will arrange a cacophony with an indeterminate result:
01:17:41.452 From Keyboard Maestro Note On 1 $64 $7F
This message will be perform wheresoever, if someone app will come across randomly!
-
I already wrote about message intercepting by DAW (it message routing will ended inside MaOS, without the possibility of sending to the periphery) or...
-
If DAW-host (LPX) will switched off, then perhaps the message will be received someone else devices or will be ignored randomly of peripheral devices, if there is no clear target/address.
Most likely the second option... according my experience - it is due to models of recipients or type of MIDI-devices.
It doesn't work as you think. The receiving device gets the SysEx command and reads F0 00 00 66 10 12, then aborts the SysEx because of the "out of bounds" 90, then processes 90 64 7F as a standard MIDI command, then drops the F7. All your logs show exactly that, regardless of source.
Not knowing much about MIDI but a bit more about protocols in general. I'm wondering if you've got something analogous to packet encapsulation going on, because it sounds like when you send the MIDI command you get various/random devices responding but SysEx lets you target a single one.
So you send the SysEx F0 00 00 66 10 12 90 64 7F F7, which targets one specific device and all others ignore the entire packet. The single target then decodes the SysEx message, dumps the first part, processes the MIDI command.
If the above is right and it's a way of turning a "broadcast" MIDI packet into a directly-addressed one, it's actually a neat workaround!
1 Like
you described all Sysex transactions correctly. I do not argue with your statements.
only the second part of the Sysex message is accepted for execution, and everything else is ignored as incomplete or undefined EOX. that's why I changed exactly this message into "Note-on channel#1 0x64 0x7F"... but only in one case (when using SendMIDI) - it reaches the goal, but in the case of using KM - it doesn't work proper!
I'll try tomorrow morning to check if the KM message was sent randomly include the rest of the studio periphery. But in this moment - I'm convinced of the result (which I've been looking for a few days before raising the discussion on the form. this is an indisputable fact...
If the above is right and it's a way of turning a "broadcast" MIDI packet into a directly-addressed one, it's actually a neat workaround!
There is no elegant solution here...
Everything is tritely simple: operable part 90 64 7F only!
The point is different – is there a destination address assignment (in my case "ipMIDI Port 1"), or it doesn't exist – "broadcast" message transmission – who will be lucky!
From this post:
Keyboard Maestro simply sends the MIDI note to the system, you then need other software to direct that MIDI note.
So it sounds like you are sending "to the system" and "the system" is using the SysEx address to target the right device. Seems to be the best you can do with what's available.
That's not how this works.
This is an MCU (Mackie Control Universal) situation; the device in question is MCU compatible. The MCU has a fairly robust implementation. Button presses and LED on/off are done via MIDI Note On commands; the motorized faders use MIDI Pitch Bend (for better resolution) and so on.
SysEx is used to transmit (from the host to the MCU) things like parameter names.
The current output routing of KM is indeed suboptimal for this; however there are workarounds (as the one using sendmidi; but there are others).
But the SysEx includes at least a "product id" -- 10 in this case. Might that, in combination with the manufacturer id, be enough to at least make "things that make sounds" ignore the SysEx?
It sounds as though when OP sends the MIDI command 0x90 0x64 0xF7, many (if not all) devices respond. When that's encapsulated in the SysEx only the targeted device responds. Those other devices dropping the entire SysEx because "I'm not that product, so it's not my problem" would certainly seem to explain the results OP is getting.
Yes -- it certainly does seem more sensible to use sendmidi or similar via a KM "Execute Shell Script" action for this rather than relying on "undocumented" behaviour!
The other devices ignore the SysEx (and I'm not quite sure if the Product ID 0x10 would do any good here anyway because that's the ID for the original Logic Control while the MCU has ID 0x14) but they still react to the Note On command.
That's not the impression I'm under; it appeared to me more as if OP didn't know how to send the plain Note On command. It certainly can't be encapsulated in a SysEx dump in that particular fashion anyway and the MCU doesn't have a valid response as well.
Yes, using sendmidi seems right now the easiest way around this. It's a bit disappointing since KM already has half the functionality built in: When using a MIDI trigger the ports can be properly selected like this:
The same would be needed for the output which right now is going to the "Keyboard Maestro" port only.
3 Likes
That's not the impression I'm under; it appeared to me more as if OP didn't know how to send the plain Note On command. It certainly can't be encapsulated in a SysEx dump in that particular fashion anyway and the MCU doesn't have a valid response as well.
You absolutely correctly understand the essence of my problem! having created the table of contents "MIDI SysEx Implementation and Assignment to External MIDI Devices", I first of all meant the use of KM and its capabilities in the implementation of MacOS GUI events to MIDI message for feedbacking external devices.
Yes, using sendmidi seems right now the easiest way around this. It's a bit disappointing since KM already has half the functionality built in: When using a MIDI trigger the ports can be properly selected like this:
are you a mean the KM INPUT port? isn't it?
The same would be needed for the output which right now is going to the "Keyboard Maestro" port only.
I'm support you!
- KM needs improvement access to list of MIDI destination ports from macOS MIDI setup. For more wide range application into audio-midi product.
Who would take care of this problem? Who Will be described in an understandable language for KM developers and will push with reasoned arguments about the need for improvements to this commercial product... Otherwise, with my knowledge in English and KM experience, my voice will not be heard 
In the meantime, I'm not ready to buy KM if it does only half the work in a MIDI environment, and the other half requires a "crutch" in the form of free SendMIDI ((
The results of the investigation into the recognition and execution of KM MIDI messages in a studio environment with peripheral equipment, DAW and stand alone VSTi:
-
When KM-sending a "pure" MIDI message
90 64 7F(Note-on only):
1.1 in a DAW: LPX is recognizes and executes the message on any AUi installed on the track in all cases (due to the MIDI KM-source is connected by default, or unless if the KM source is forcibly not disabled (using Logic inviroment));
1.2 in Stand alone VSTi - recognition and execution occurs only in the case of a specific assignment of the KM source to the input port of the VSTi;
1.3 MIDI receiving peripherals (with USB-MIDI, ipMIDI, or by other ethernet connection protocols) do not recognize and therefore do not execute this message (whether in the host-off or host-on DAW state). this statement is limited to the list of my equipment, therefore it is not absolute! (SSL nucleus 2 controller via ipMIDI, Roland integra-7 and Korg Kronos synths via USB-MIDI, Korg OASYS synth via ethernet connection using Mio10 MIDI patchbay). -
When KM-sending the raw SysEx (
F0 00 00 66 10 12 90 64 7F F7- which a priori controversial / incorrect method for sending an encapsulated message part as "Note-on":90 64 7F):
2.1 SysEx not recognized by DAW! Even if partially interpreted as Note-on part from SysEx);
2.2 Stand alone VSTi - continues to recognize encapsulated Note-on part when forcing KM-suorce to MIDI input port of VSTi;
2.3 - peripheral equipments - will not recognize this message in any case.
Сonclusion:
-
MIDI "Note-on" message from KM source is only executed within MacOS (DAW or SA VSTi) unless MIDI input is forced disabled in MIDI-inviroment settings, or AUi/VSTi channels are inconsistent
-
A MIDI "Note-on" message encapsulated in SysEx and sent from the KM - only Stand Alone VSTi that are preset to the KM source are recognized. in other cases - the message is ignored! which is to be expected, according to the theoretical description of the MIDI implementation chart.
-
At this time the Keyboard Maestro cannot and doesn't have the ability to send the required MIDI messages to certain/expected peripheral equipment without "crutches" software-intermediaries! Including as feedback to MCU-emulation controllers.
In other words - there is no difference between the malformed SysEx message and the plain Note On as far as the reactions of the various components go.
Probably 90%.
The only difference is the interaction with the DAW.
Since LPX does not respond to SysEx followed by 90 64 7F.
Probably due to a conflict or preferences between the Logic control driver for SysEx header like:
F0 00 00 66 10 12 - Logic control ID, although I diversified between
F0 00 00 66 14 12 - MCU ID,
F0 00 00 66 15 12 - XT ID,
All attempts to calculate the remainder after that - do not give a result...
I found another tip:
How to make a peripheral tone generator (synthesizer) play after a KM note action
- Is to set in logic environment – direct connection between source
"Keyboard Maestro" to a separate "output" element with assignment to the desired synthesizer port, but that doesn't make sense for this topic.
Unfortunately those assignments to the MCU controller, these trick do not wor
Why on earth should Logic react to that malformed SysEx message? There are very few SysEx messages coming FROM the MCU; nearly every SysEx communication is going TO the MCU.
Among those few SysEx messages sent by the MCU are the host connection and initialization (when starting up) and the Firmware revision when requested - and that's basically it. Everything else is going to the MCU.
BTW:
The 0x12 after the model ID always signals an update to the LCD (followed by the data in question). From the manual:
Example:
The following message writes “Hello” to top left of the LCD on a Logic Control master section:
F0 00 00 66 10 12 00 48 65 6C 6C 6F F7
Works for me as long as I change the model ID to 0x14.
1 Like
I checked all the message options... I was interested workflow FROM KM TO MCU first of all! and described different recipients behavior...
First of all you asked me before about the general difference when receiving a signal to the console/controller or about the reverse movement from the controller to the DAW?
I did not understand our disagreements in the dialogue... 
I've talked about sending messages from KM and the observed reaction on the side (whether it's a DAW-host or a stand-alone instrument plugin, or an external hardware peripheral). If you are not interested, you could not criticize – otherwise, let's find working solutions to the problem!
About the details/or syntax of the MIDI message I'm showing here - this is the Note-on code that I receive from the controller and it's LED when manipulated. and therefore I try to get an identical SysEx signal using the Keyboard Maestro and an adequate controller response to a similar signal from outside the LPX (from KM as a source of signal).
This code by KM raw message does not work for my controller...
but works fine with SendMIDI (even if I change the MCU code to 14) - the result is the same
F0 00 00 66 10 12 00 48 65 6C 6C 6F F7
F0 00 00 66 14 12 00 48 65 6C 6C 6F F7
Yes, and they were 100% identical, not 90%.
I wouldn't insist on being 100% sure of my result...
But it's safe to say that KM is releasing a raw MIDI-data message to core MIDI as a "broadcast" network (exept proper SysEx! for example: a banal ASCII-string on LCD "hello" F0 00 00 66 10 12 00 48 65 6C 6C 6F F7- KM is unable to successfully send). And only the "elite" soft-environment of the computer can use it, which, either by default or by directive, can assign themselves listening to the KM port. But for "stupid" controllers, patch-bay or tone generators with "control surface" functions - these "signals from space" core MIDI are unfortunately not available! For they are controlled by proprietary drivers and there is no way to modify them... and the MIDI policy itself is organized not to interfere in the internal affairs of developers... but only as a traffic controller.
But my experience and intuition did not disappoint me:
Sorry, but all of that's wrong or still not completely understood.
Once more: You're not sending an "encapsulated" Note On. You're sending an incomplete SysEx block followed by a Note On and an illegal character. All receivers ignore the incomplete SysEx block, process the Note On and ignore the illegal character (if they receive on the Keyboard Maestro MIDI port).
Compare that to sending just a Note On directly: All receivers process the Note On (if they receive on the Keyboard Maestro MIDI port).
That's 100% the same behavior as far as the results go.
I'm out now.
Lol! But I agree 90%
But then answer the 2 previous facts:
- Why is the SysEx remainder =
90 64 7Fnot processed in the DAW? if direct "note-on" message for LPX - processed! - Why "canonically correct" SysEx "Hello" is not processed?
F0 00 00 66 10 12 00 48 65 6C 6C 6F F7