yes I understood you
Spy ON full control of MIDI ports
just without LPX Logic control nothing happens on the MIDI monitor log screen when sending SendMIDI messages
I had managed to get some result by sendMIDI strings
for Note on/off = "on"-command or "note-on" work too:
sendmidi dev "ipMIDI Port 3" on hex 64 7F or
sendmidi dev "ipMIDI Port 3" hex on 64 7F or
sendmidi dev "ipMIDI Port 3" on 89 127 or
sendmidi dev "ipMIDI Port 3" note-on 89 127 - all four commands give the same result! But sendMIDI dont recognized syntax hex 90 or 0x90 as a "Note on" commands!
pay attention: "Note off" - same like "Note-on" with velocity value 00:
sendmidi dev "ipMIDI Port 3" on hex 64 00 or
sendmidi dev "ipMIDI Port 3" hex note-on 64 00 or
sendmidi dev "ipMIDI Port 3" on 89 00
for CC# message:
sendmidi dev "ipMIDI Port 5" cc hex 47 7F
sendmidi dev "ipMIDI Port 5" cc hex 47 00
but unpossiable to send Sysex message and
I cæn‘t to understand how to work the "virt"- command yet because all "ipMIDI" are virtual ports…
Hooray! I managed to get the sysex message sent via SendMIDI after talking to the author gbevin on the discord.com forum.
Tere is his answer:
Hex merely switches how next numbers are implemented, it doesn't send raw bytes (see docs), use raw for raw bytes. Virt-command creates a new virtual midi device for sendmidi, it's unrelated to other devices being virtual or not. Running status is not used in sendmidi...
After such a brief explanation, I send any SysEx! and they achieve their goal! and even that "wrong" Sysex - which did not reach the addressee earlier - also works with sequestered part 90 64 7F!
sendmidi dev "ipMIDI Port 1" raw hex F0 00 00 66 10 12 90 64 7F F7
In fact - this is message may be cut down to:
sendmidi dev "ipMIDI Port 1" raw hex 90 64 7F
Or in decimal:
sendmidi dev "ipMIDI Port 1" raw 144 100 127
It will be single result!
Note:
-
raw-command have necessary be written with Sysex status bytes F0 ... F7
-
itsn't work with Note-off format of message:
sendmidi dev "ipMIDI Port 1" raw 128 100 127
Midi monitor log view:
22:26:52.647 To ipMIDI Port 1 SysEx Loud Technologies / Mackie $6 bytes F0 00 00 66 10 12
22:26:52.647 To ipMIDI Port 1 Note On 1 $64 $7F
22:26:52.647 To ipMIDI Port 1 Invalid $1 bytes
22:27:16.103 To ipMIDI Port 1 SysEx Loud Technologies / Mackie $6 bytes F0 00 00 66 10 12
22:27:16.103 To ipMIDI Port 1 Note Off 1 $64 $00
22:27:16.103 To ipMIDI Port 1 Invalid $1 bytes
It's frustrating that the KM is unable to specify and route a raw-MIDI message to a specific destination port ((
it's like a missing "5-element" to save a certain part of humanity dealing with MIDI inviroment...
here is a comparison of logs of identical raw-messages F0 00 00 66 10 12 90 64 7F F7 executed separately into:
- by Keyboard Maestro action
23:48:24.300 From Keyboard Maestro SysEx Loud Technologies / Mackie $6 bytes F0 00 00 66 10 12
23:48:24.300 From Keyboard Maestro Note On 1 $64 $7F
23:48:24.300 From Keyboard Maestro Invalid $1 bytes
- by SendMIDI command
23:48:46.674 To ipMIDI Port 1 SysEx Loud Technologies / Mackie $6 bytes F0 00 00 66 10 12
23:48:46.674 To ipMIDI Port 1 Note On 1 $64 $7F
23:48:46.674 To ipMIDI Port 1 Invalid $1 bytes
The syntax of the raw sources is the same, but the direction of impact and results are different!
KM to become a truly full-fledged app needs to be finalized to assign MIDI destinations.
1 Like
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%.