MIDI SysEx Implementation and Assignment to External MIDI Devices

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

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:

  1. 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).

  2. 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:

  1. 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

  2. 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.

  3. 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...
:man_shrugging:

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... :face_with_head_bandage:

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 7F not 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

:man_shrugging:

=== wrote all this before realizing the depth and intensity of the subsequent conversation; I'll leave up for any beginners hitting this. ===

hi @Vladistone and welcome to the forum.

  1. "start" sysex you probably mean sysex transfer. i know that with an app like Logic Pro, if you are recording MIDI on a MIDI track, you simply send it sysex packets and it will record them.

  2. KM responds to MIDI triggers: note, controller, packet. in order to receive MIDI sysex in KM, you'll need to 'listen for' the packet you want

  3. see Audio MIDI Setup ... all CoreMIDI (Apple's own MIDI manager) options are available within KM. note also that you can change the names of devices in Audio MIDI Setup and this will helpfully be reflected in KM.

  4. incoming MIDI notes/controllers/packets can arrive from a DAW or keyboard to KM and trigger things.

  5. on the outgoing side, your Actions/MIDI are:
    Send MIDI Note On
    Send MIDI Note Off
    Send MIDI Control Change
    Send MIDI Packet
    ..... use these to send MIDI out of KM to anything defined in Audio MIDI Setup (coreMIDI), (including Network MIDI).

  6. to play a key on your keyboard and use KM as a rerouter/rechannelizer - you'll likely not have the performance timing you're looking for: you'd need to set up a MIDI note trigger, figure out how to capture which note/channel, and resend out using Actions. probably not what you want and there are other MIDI utilities for this.

  7. "rotation": Audio MIDI Setup (CoreMIDI) is the software which runs between MIDI aspects of macOS and your defined attached MIDI interfaces, keyboards etc.

example of what i think you're after:
hit a key on Maschine, send sysex packet to Bass Station would look like:

  • macro in a macro group is set up with a MIDI trigger:
  • [define note] is pressed; on [define channel]; from [Maschine]
  • (note: MIDI Learn feature)
  • triggers..... Will execute the following actions:
  • Send MIDI Packet (channel and device here are unclear to me - do they follow from the trigger channel and device??) / Send raw packet

... from here you will understand the features and limitations available.

:open_mouth: holy mackerel

Hi @renton
it is very difficult to follow your comments without reference to the original source ...
but I will try to disappoint you with one task described above:

  • Try sending a ASCII-message to an external MIDI device with multiple input ports: "Hello word" or as 72 101 108 108 111 32 119 111 114 100 33 form of a KM Sysex message and you will understand that it will not be delivered! If you do not provide a "gasket" for KM in the form of other applications to rotation of the message to the desired device port.

  • I'm not interested in techniques for receiving and processing MIDI events using KM. (There are free specialized programs for this, for example, Send MIDI, MIDI pipe, and so on).

  • I was hoping to use KM's ability to read GUI events and translate them into raw MIDI messages with the correct external device port assigned.

But apparently neither one nor the other way to explain GUI-source triggering and targeting to MIDI devices was found by forum users.

1 Like

indeed, I misunderstood you. hope you worked it out!