interception of hidden LPX events

[vladistone]

 

Hi there!
Tell me, are there any ways or tools for intercepting hidden Logic events that the LPX receives/sends to the MCU?
but are not captured by normal tools such as the MIDI monitor app?

for group buttons MCU w/functions feedback such as:
- Shift, Option, Control, Alt (not to be confused with ASCII-keystroke)
- Escape, Enter, Undo
- Global, User, Groupe e t.c.

the first example that I paid attention to is the UNDO button, which receives a signal for any change in the LPX parameter

My idea is that there are GUI events ( such as GUI "Compare" button) that don't send messages to external controllers, but it's possible to track them! but costly because:
Changing of state cannot be used as a trigger unless the state generates an event.  But to continuously poll and application's state would be prohibitively expensive in CPU and battery.

So, If by receiving events for the UNDO button - then it is possible to use it as a trigger to record initiator of the another event (for example: "Compare" button)!

NOTE:

I immediately dissect the arguments on the account of the fact that "there are the UNDO / REDO or ⌘ + Z / ⇧ + ⌘ + Z buttons - have to use for these purposes!"
the answer is obvious:

• there can be many manipulations in the change chain when adjusting the FX parameters, and the "compare" button manipulates all of them at one click.
• "bypass" has other restrictions on starting or turning off FX in real time.

 

 

Edited March 23, 2023 by vladistone

[gacki]

On 3/23/2023 at 5:57 AM, vladistone said:

the first example that I paid attention to is the UNDO button, which receives a signal for any change in the LPX parameter

The Undo button doesn't receive any signal at all. The Undo LED receives a signal and the Undo button sends one. Both are completely unrelated to each other (communication-wise) even though they use the same command. All that "tracking" (when to light the LED and when to perform an Undo operation) is done by the "control surface" driver. If the LED is lit and you press the button this does not turn off the LED by itself. Instead the driver receives the command from the Undo button and in turn sends it to the LED.

The LED uses a Note On for Note #81 (velocity 127 to turn it on, 0 to turn it off); the button uses the same note with velocity 127 for press and 0 for release.

[des99]

On 3/23/2023 at 4:57 AM, vladistone said:

Tell me, are there any ways or tools for intercepting hidden Logic events that the LPX receives/sends to the MCU?
but are not captured by normal tools such as the MIDI monitor app?

The only traffic Logic sends to the MCU is MIDI traffic, which can be observed by any MIDI monitor tool. There are no "hidden events" received or sent to the MCU.

On 3/23/2023 at 4:57 AM, vladistone said:

for group buttons MCU w/functions feedback such as:
- Shift, Option, Control, Alt (not to be confused with ASCII-keystroke)
- Escape, Enter, Undo
- Global, User, Groupe e t.c.

All the modifier keys do in Logic is to change the Modes that are active, so that a next button press does something different to what it did when, eg Shift wasn't pressed. Logic doesn't send MIDI traffic in response to these events, they switch Modes in the controller assignments (generally).

On 3/23/2023 at 4:57 AM, vladistone said:

My idea is that there are GUI events ( such as GUI "Compare" button) that don't send messages to external controllers, but it's possible to track them!

It's possible to detect the *button presses* from the controller, because they just send regular MIDI to Logic ("I've just pressed the Shift button" etc). It's not (easily) possible to query what Mode a given zone is in though - controllers were always designed to be "dumb" and be managed by Logic, and therefore the MCU scheme doesn't really have a way of externally determining state, as such (annoyingly enough).

One of these days I'll dig into the OSC protocol to see what's going on here, because Logic uses this to communicate between Logic and Logic Remote, and I think there's state transmission going on here. It may be that the OSC communication protocol in Logic offers some advantages over the older MCU protocol...

Edited March 25, 2023 by des99

[vladistone]

2 hours ago, gacki said:

The Undo button doesn't receive any signal at all. The Undo LED receives a signal and the Undo button sends one. Both are completely unrelated to each other (communication-wise) even though they use the same command. All that "tracking" (when to light the LED and when to perform an Undo operation) is done by the "control surface" driver. If the LED is lit and you press the button this does not turn off the LED by itself. Instead the driver receives the command from the Undo button and in turn sends it to the LED.

The LED uses a Note On for Note #81 (velocity 127 to turn it on, 0 to turn it off); the button uses the same note with velocity 127 for press and 0 for release.

@gacki thanks for correcting my request! this is exactly what I wanted to say earlier! Sorry for my not quite correct explanation of the problem! just... :

- how you intercept the message "Note On for Note #81" for UNDO LED? if it "control surface" driver generation..., Which don`t recognizing by MIDI moniror or by other apр?  

Edited March 26, 2023 by vladistone

[vladistone]

2 hours ago, des99 said:

The only traffic Logic sends to the MCU is MIDI traffic, which can be observed by any MIDI monitor tool. There are no "hidden events" received or sent to the MCU.

to this answer, I'll repeat my question earlier:

26 minutes ago, vladistone said:

@gacki thanks for correcting my request! this is exactly what I wanted to say earlier! Sorry for my not quite correct explanation of the problem! just... :

- how you intercept the message "Note On for Note #81" for UNDO LED? if it "control surface" driver generation..., Which don`t recognizing by MIDI moniror or by other apр?  

 

2 hours ago, des99 said:

..All the modifier keys do in Logic is to change the Modes that are active, so that a next button press does something different to what it did when, eg Shift wasn't pressed. Logic doesn't send MIDI traffic in response to these events, they switch Modes in the controller assignments (generally).

but such modifier buttons have LED - and I would like to control these operations of turning on / off the backlight of the buttons - as an additional feedback for "Logic control"... 

- maybe there are ideas how to make react to LPX changes for LED elements (shift, alt, option, cntrl)?

2 hours ago, des99 said:

It's possible to detect the *button presses* from the controller, because they just send regular MIDI to Logic ("I've just pressed the Shift button" etc). It's not (easily) possible to query what Mode a given zone is in though - controllers were always designed to be "dumb" and be managed by Logic, and therefore the MCU scheme doesn't really have a way of externally determining state, as such (annoyingly enough).

okay! It's annoying that there is no sysex request for the state of the mode buttons! as well as the ability to customize these buttons for toggle behavior

2 hours ago, des99 said:

One of these days I'll dig into the OSC protocol to see what's going on here, because Logic uses this to communicate between Logic and Logic Remote, and I think there's state transmission going on here. It may be that the OSC communication protocol in Logic offers some advantages over the older MCU protocol...

I also tried to monitor the traffic of OSC messages, but did not achieve the required success:

we will hope to your investigation of OSC-MIDI

Edited March 26, 2023 by vladistone

[gacki]

7 hours ago, vladistone said:

- how you intercept the message "Note On for Note #81" for UNDO LED? if it "control surface" driver generation..., Which don`t recognizing by MIDI moniror or by other apр?  

MIDI Monitor works fine for me; you need to enable "Spy on output to destinations" and select the port in question (all under "Sources").

7 hours ago, vladistone said:

- maybe there are ideas how to make react to LPX changes for LED elements (shift, alt, option, cntrl)?

I don't think those four have any LED attached.

7 hours ago, vladistone said:

It's annoying that there is no sysex request for the state of the mode buttons!

They don't have a state! A SysEx request would make no sense for this.

The MCU is under complete control of the "control surfaces" driver. This driver tracks which buttons were pressed and what to display on the MCU in return. The MCU by itself doesn't have a state. You can think of it (somewhat simplified - the motor faders are clearly a separate issue) as two separate "dumb" devices: one that generates MIDI messages from button presses and v-pots and sends them via MIDI Out; and another one that displays stuff according to information it receives via MIDI In. Those two functionalities are tied together in the MCU driver in Logic (or any other DAW).

 

[vladistone]

40 minutes ago, gacki said:

MIDI Monitor works fine for me; you need to enable "Spy on output to destinations" and select the port in question (all under "Sources").

Thanks! I will try to trace this fact!

41 minutes ago, gacki said:

I don't think those four have any LED attached.

My MCU-emulated controller have it. buttons are reassignable

[des99]

12 hours ago, vladistone said:

but such modifier buttons have LED - and I would like to control these operations of turning on / off the backlight of the buttons - as an additional feedback for "Logic control"... 

Logic sends this MIDI message where necessary to the MCU. It's regular MIDI traffic, and can be monitored as such.

It's the Control Surface module code that sends all these feedback messages by the way.

12 hours ago, vladistone said:

maybe there are ideas how to make react to LPX changes for LED elements (shift, alt, option, cntrl)?

LPX does not react to changes in LEDs. You press a button, a MIDI message for that button press gets sent to Logic, Logic does the appropriate task (eg switches Mode), and the control surface sends the feedback "light the button LED" to the control surface.

Lighting LED's is done by Logic, not the controller. Only some buttons have integrated LED's, and these are all defined in the control surface module code in the case of the MCU.

12 hours ago, vladistone said:

as well as the ability to customize these buttons for toggle behavior

All controller assignments can be modified, so you can change many of these behaviours if you want. What you can't change is the custom behaviour contained in the control surface module code.

 

Edited March 26, 2023 by des99

[vladistone]

1 hour ago, des99 said:

Logic sends this MIDI message where necessary to the MCU. It's regular MIDI traffic, and can be monitored as such.

It's the Control Surface module code that sends all these feedback messages by the way.

LPX does not react to changes in LEDs. You press a button, a MIDI message for that button press gets sent to Logic, Logic does the appropriate task (eg switches Mode), and the control surface sends the feedback "light the button LED" to the control surface.

Lighting LED's is done by Logic, not the controller. Only some buttons have integrated LED's, and these are all defined in the control surface module code in the case of the MCU.

All controller assignments can be modified, so you can change many of these behaviours if you want. What you can't change is the custom behaviour contained in the control surface module code.

You are correct in your explanation! But I'm afraid we did not understand each other from the very beginning! It is my fault that I could not explain the essence of my requests and for what purpose!
I'm looking forward to getting some hints for coding or tool or a way to manage these processes FROM host TO controller! and not vice versa, as you tried to explain to me above ...
That is: if the Logic control has the ability to control the LED signaling of the controller, but does not do this for the reason - the standard settings for the behavior of the MCU, then why don't we customize this process by intercepting some events and send the changes to the MCU as we want?
For example: assign "Shift" button into "toggle mode" behavior!?
or - use LED of "Shift" - for the same GUI FX window for feedback of the "compare" button?!

I hope you understand me?

Edited March 26, 2023 by vladistone

[des99]

29 minutes ago, vladistone said:

I'm looking forward to getting some hints for coding or tool or a way to manage these processes FROM host TO controller! and not vice versa, as you tried to explain to me above ...

I was just correcting some of your explanations as to what's happening, so you understand it better.

29 minutes ago, vladistone said:

if the Logic control has the ability to control the LED signaling of the controller, but does not do this for the reason - the standard settings for the behavior of the MCU, then why don't we customize this process by intercepting some events and send the changes to the MCU as we want?

You can send whatever MIDI data you want to the MCU - turning the LED on for a specific button is a single MIDI message. However, you'll possibly need to send that MIDI traffic a different route, because in Logic, all traffic to an MCU goes through the control surface module code, and it simply won't pass MIDI traffic that isn't valid.

At the same time, the MCU won't recognise MIDI traffic it doesn't understand anyway, so it wouldn't achieve anything.

29 minutes ago, vladistone said:

for example: assign "Shift" button to toggle mode!?

You can already change the behaviour of these buttons, by editing the controller assignments that respond to the shift button.

Logic sends nothing *back* to the shift button at all - it just receives the button press, which triggers whatever controller assignment is valid based on the current mode.

29 minutes ago, vladistone said:

or - use LED Shift - for the same GUI FX window for feedback of the "compare" button?!

There is no "Shift LED" on an MCU. You're trying to send a MIDI message that isn't defined through a control surface module that doesn't recognise that message anyway, to a control surface that doesn't recognise that message to a hardware control that has no LED on it - so it's not clear to me what you are trying to do at all.

I'm not sure you are understanding how the MCU works from mine, or @gacki's excellent descriptions. You can't use any "Shift LED" message, as this is not a thing.

You could use a button that actually *has* an LED, but as with all things customising control surfaces, you have to design in with the existing behaviour so you don't break things. Logic won't stop sending valid traffic to the MCU to light a particular LED in a given context, and that will interfere with using it for something else.

Really, the proper way of interfering and modifying Logic's traffic between itself and an MCU is to put an intelligent agent (ie, an app/script or whatever) that is custom designed to modify this traffic. I have built exactly such an app, so I have a good idea of what this involves (mine is more complex, as it actually pretends to be a valid MCU to Logic, so it has traffic between the app and Logic, and also responds to a different MIDI controller, and it therefore translates a non-MCU controller to what Logic thinks is an MCU.)

I'm not sure the concept of what you are trying to do is valid, but it's possible I'm not understanding you well.

If you have some other device (not a real MCU, but an app or something) and implement your own "Shift LED" message to do something, and manage the state of this via other means, than you can do that - but that's nothing to do with Logic, which won't do it, as the control surface module won't implement such an LED light, nor pass feedback to it.

(I think I mistyped "shift LED" at least five times writing that..! Don't ask!)

Edited March 26, 2023 by des99

[gacki]

5 minutes ago, des99 said:

There is no "Shift LED" on an MCU.

He's using a SSL Nucleus 2 in MCU mode; and it appears that those buttons are indeed backlit. Whether that's a backlight that is controlled by some MCU protocol function unknown to us or simply a backlight that is activated by the button press (and automatically turns off when releasing the button) I don't know. I think the Nucleus can also operate in Eucon mode; and perhaps there are functions for this in this mode.

[des99]

6 minutes ago, gacki said:

He's using a SSL Nucleus 2 in MCU mode; and it appears that those buttons are indeed backlit.

Thanks, the context is useful, as it was missing from the above posts.

I'd guess this is a function of the hardware and nothing to do with Logic, but observing the MIDI traffic would clear that up quickly enough.

Edited March 26, 2023 by des99

[gacki]

5 minutes ago, des99 said:

Thanks, the context is useful, as it was missing from the above posts.

To be fair, it was in the last line of

(The "MCU-emulated controller" is a link; and yes; posting this information directly would have been better. There's also a language barrier.)

6 minutes ago, des99 said:

I'd guess this is a function of the hardware and nothing to do with Logic, but observing the MIDI traffic would clear that up quickly enough.

Indeed. But it's definitely an interesting question: Could a MCU-protocol control surface somehow be forced to operate Logic functions that are not immediately accessible?

[des99]

24 minutes ago, gacki said:

(The "MCU-emulated controller" is a link

Thanks, yes I saw the text, but didn't really know what it referred to (whether it was hardware, or a software script or something). I'm not sure it was a link when I saw it either, but either way I don't really want to go hunting in other threads for information that may or may not be relevant... 🙂 No matter, I just missed it...

24 minutes ago, gacki said:

Could a MCU-protocol control surface somehow be forced to operate Logic functions that are not immediately accessible?

From my control surface module hacking (and my memory!), the control surface module simply blocks traffic it doesn't understand. So, if you custom created a "Shift LED" message, it's not a function the control surface module understands, for a control it understands, and instead of silently passing it through, it blocks it.

The same is true for different device types - eg, a C4 has different buttons/lights etc than an MCU. If you try to send an LED for an MCU button to the C4, the control surface module sees it's not valid for the C4, and blocks it.

(This particularly has been quite problematic for my code, as eg for the MCU you can determine what main Assign mode the controller is in because each of those major modes has an associated LED - so you can track the status of those LEDs to programmatically determine the Assignment Mode the controller is in. Super useful. However, the C4 doesn't have those mode buttons, and thus no assignment mode LEDs, and thus you can't determine the assignment mode it's in, as Logic no longer sends those LEDs to the C4. And you can't "fake it" either, as those feedback messages from the assignment modes don't get past the control surface module, which recognises they are invalid in that context. This is a particularly hard problem for me to solve in my app, which has to try to infer the current assignment mode of the C4 using other means.)

Edited March 26, 2023 by des99

[gacki]

I was thinking along a different line: The MCU has (for example) eight function keys that can be somewhat freely assigned; by default they call up screensets 1 to 8. Now let's imagine I wanted to use one of those keys to trigger the "Compare" button in a plugin. So I have a command coming from the MCU but how do I connect this to the button? There is no key command for "Compare"... (at least not on 10.5.1).

 

[des99]

I get a bit lost, as there seem to be so many threads talking about this compare button, and I thought the OP was dealing with this elsewhere.

There is no mechanism in Logic that I know of for programmatically pressing the compare button (eg key shortcut, etc), so something else would have to do this. I previously suggested that I would use Keyboard Maestro for such as task, but the OP didn't like that solution and was using a different approach, so I bowed out of that thread, as I couldn't help further.

In any case, in your example, I would simply make sure the F-keys weren't triggering something in Logic (to avoid collisions), and simply make those MIDI messages on that incoming MIDI port trigger a KM macro which recognises the compare button (and it's state) in the top window (or whatever), and either clicks or doesn't click it appropriately. (Or based on it's state, sends a particular MIDI message, etc, as required). I do this kind of thing all the time, and KM is (imo) the best tool for these kinds of things.

If you wanted to actually hijack the F keys traffic so it never reached Logic at all, again, you'd need something else to do that - eg, using MIDIpipe where you can hijack a port, filter certain traffic from it, and route that traffic elsewhere, but then you'd need MIDIpipe running all the time and I find implementations with too many individual pieces cumbersome in practice.

Edited March 26, 2023 by des99

[vladistone]

An excellent conversation went in a theoretical direction, and maybe in a practical one as the liquidation of illiteracy. but everything you are talking about now around the "compare button" is implemented in two ways using KM and HS but not in the opposite direction:
when you're expecting a symmetrical on/off change of the blue UI "compare" color in the FX options window and on the control surface (SSL core or other similar MCU).
the fact that the Nucleus 2 has incredible ability to reconfigure its control modes and different generation protocol (MIDI, CC, ASCII) at the same time - it does not matter for MCU emulation paired with LPX ... but it sets interesting thoughts around universal buttons with LCD backlighting , which were assigned by default as MODE-switches but can change depending on the user's desire

Edited March 26, 2023 by vladistone

[gacki]

It's rather clear to me to see why this is difficult to impossible to implement. Pressing the "Compare" button is more or less a one-way street and hence straightforward. What is difficult to impossible is to detect its state and to transfer it back to the control surface. Why is that so?

Imagine the following scenario: You have two or more plugin windows open; and in only one of them the button is active. You would have to track the status of the button for the frontmost plugin window somehow and make the control surface react appropriately. I don't think this can be done with external tools safely.

[vladistone]

10 minutes ago, gacki said:

It's rather clear to me to see why this is difficult to impossible to implement. Pressing the "Compare" button is more or less a one-way street and hence straightforward. What is difficult to impossible is to detect its state and to transfer it back to the control surface. Why is that so?

Imagine the following scenario: You have two or more plugin windows open; and in only one of them the button is active. You would have to track the status of the button for the frontmost plugin window somehow and make the control surface react appropriately. I don't think this can be done with external tools safely.

KM allows you to do these manipulations with the accuracy of the "very first window". there is no problem with waiting, if only you opened the two windows and got confused yourself between them looking to the other side of the screen... but this is not a destructive button - it does not break the process or you can make releas.
Perhaps we are carried away with accents on this button. as there are other interesting moments and unrealized buttons and LCD...
the only answer I got was that KM. cannot control the destinations of the send address of the message. But it is possible via MIDI pipe or SendMIDI

Edited March 26, 2023 by vladistone

[Jordi Torres]

3 hours ago, gacki said:

It's rather clear to me to see why this is difficult to impossible to implement. Pressing the "Compare" button is more or less a one-way street and hence straightforward. What is difficult to impossible is to detect its state and to transfer it back to the control surface. Why is that so?

Imagine the following scenario: You have two or more plugin windows open; and in only one of them the button is active. You would have to track the status of the button for the frontmost plugin window somehow and make the control surface react appropriately. I don't think this can be done with external tools safely.

Here is getting exactly that behavior orchestrated with the help of a single Hammerspoon (Lua) script:

To be fair the above does rely on a bit AppleScript plus the SendMIDI command-line tool for sending a MIDI command out a specific MIDI port in response to the values gotten from the Compare button state.

The same could be achieved with Keyboard Maestro for those who prefer that tool.

J.

[gacki]

I'm not 100% sure how this tracks different existing plugin windows with different "Compare" values. Do we run that script every time an open window gets activated?

 

[Jordi Torres]

16 minutes ago, gacki said:

I'm not 100% sure how this tracks different existing plugin windows with different "Compare" values.

It doesn't. With the script I'm using in that example, it acts upon whichever plugin window has focus.

18 minutes ago, gacki said:

Do we run that script every time an open window gets activated?

That particular script works like this:

If Logic is the frontmost application, Hammerspoon listens for a specific MIDI event coming from my MIDI controller and it uses that to call an AppleScript to turn the Compare button on/off. The same function triggers an AppleScript to get the value (0 or 1) of the button's state. Those values are then multiply by 127 passed to SendMIDI via string interpolation to be used as the second data byte value of the CC20 being sent to the chosen output port.

J.

[des99]

39 minutes ago, Jordi Torres said:

With the script I'm using in that example, it acts upon whichever plugin window has focus.

Yeah, that's the most sensible way of implementing this imo.

39 minutes ago, Jordi Torres said:

If Logic is the frontmost application, Hammerspoon listens for a specific MIDI event coming from my MIDI controller and it uses that to call an AppleScript to turn the Compare button on/off. The same function triggers an AppleScript to get the value (0 or 1) of the button's state. Those values are then multiply by 127 passed to SendMIDI via string interpolation to be used as the second data byte value of the CC20 being sent to the chosen output port.

Pretty sensible. If I was doing it, I'd skip the Applescript part and just use KM's image detection to check the state of the compare button (ie, is it the black one, or the blue one?), which simplifies things a bit, or just click it if you're setting it via MIDI.

Edited March 26, 2023 by des99

[vladistone]

5 hours ago, Jordi Torres said:

Here is getting exactly that behavior orchestrated with the help of a single Hammerspoon (Lua) script:

To be fair the above does rely on a bit AppleScript plus the SendMIDI command-line tool for sending a MIDI command out a specific MIDI port in response to the values gotten from the Compare button state.

The same could be achieved with Keyboard Maestro for those who prefer that tool.

J.

In the HS vs KM competition this time HS will take half a step ahead. it's already fun. But! I see the following drawback or nuance of such a solution (correct me if I'm not wrong):
- @Jordi Torres used the CC# to manipulate the controller (rather than the standard MCU mode which uses almost the full range of MSB:LSB bytes in send/return messages). isn't it?

- Plus exists the limits for using SysEx messages to only LSB byte range up to 0x80 (earler mentioned)...
- This is a small problem for me with a universal controller wich capable of receiving both data and CC messages. But may not be acceptable for other users MIDI-hardware!
- None of the HS or KM applications handle such tasks on their own, and manipulation is required transfer to the "helper" to assign certain MIDI ports (SendMIDI or possibly MIDI pipe) and plus using the "recognizer" of GUI events - script coding (applescript or whatever), and as a consequence:
- You need to delve into the knowledge and syntax of scripting languages (AS, Lua, HS-integration or JS) - which is quite a lot for the learning curve...
Summarizing the results:
- The "arms race" will be won by the one who quickly implements the proper provision of MIDI messages to the destination and a friendly UI for setting up the event handling mechanism.

Regards, Vladistone

Edited March 27, 2023 by vladistone

[Jordi Torres]

On 3/27/2023 at 3:27 AM, vladistone said:

- @Jordi Torres used the CC# to manipulate the controller (rather than the standard MCU mode which uses almost the full range of MSB:LSB bytes in send/return messages). isn't it?

I was just demonstrating that it is possible to send out MIDI messages in response to the state of that button. Which messages you send entirely is up to you. 

Also, if you do something similar to my example, you don't necessarily need to capture the button's 0 and 1 values to then use them as part of the messages you send, you could use them to trigger the messages you want to send.

On 3/27/2023 at 3:27 AM, vladistone said:

None of the HS or KM applications handle such tasks on their own, and manipulation is required transfer to the "helper" to assign certain MIDI ports

Hammerpoon's hs.midi extension is basically a wrapper for MIKMIDI which does allow to send MIDI out to available destinations, but for whatever reason that functionality is not available through hs.midi. We can only use inputs.

But I'm glad I found out about SendMIDI, I like it.

On 3/26/2023 at 11:38 PM, des99 said:

If I was doing it, I'd skip the Applescript part and just use KM's image detection to check the state of the compare button (ie, is it the black one, or the blue one?), which simplifies things a bit

In this case it's a very simple AppleScript so it doesn't bother me. It works fine. However, an alternative to AppleScript within HS which seems very powerful but I haven't had the time to play with it yet is the hs.axuielement module which gives you access to the macOS's Accessibility API through HS.

That image detection functionality in KM reminds me of good ol' Sikuli (these days called SikuliX).

J.

Edited March 28, 2023 by Jordi Torres

[vladistone]

For me, this dialogue turned out to be very informative. I applaud your enthusiasm and thoroughness in explaining the nuances of the MIDI Implementation Chart.
I once again studied the capabilities of KM for working with peripheral equipment and made my conclusions, which I published here and on the KM forum (I hope they don’t ban me there?)... which, at first glance, seemed the most attractive because of the GUI, but alas ... the conclusions are still disappointing and remain the same - coding & soft combination 🤕

 

Quote

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

The results of investigation into the recognition and execution of KM MIDI messages in a studio environment with peripheral equipment, DAW and stand alone VSTi

remark: participated in the experiment without written consent and none of the subjects were harmed (affected by SysEx) ☠️: 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 e t.c.

• 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!

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

 

 

Edited March 29, 2023 by vladistone

[vladistone]

53 minutes ago, vladistone said:

The results of investigation into the recognition and execution of KM MIDI messages

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

 

I'll be happy if 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 experience, my voice will not be heard...

If KM does only half the work in a MIDI environment, and the other half requires a "crutch" in the form of SendMIDI. So the Keyboard Maestro needs improvement access to list of MIDI destination ports of macOS. For more wide range application into audio-midi product. 

 

 

Edited March 29, 2023 by vladistone

[vladistone]

 

9 hours ago, Jordi Torres said:

Hammerpoon's hs.midi extension is basically a wrapper for MIKMIDI which does allow to send MIDI out to available destinations, but for whatever reason that functionality is not available through hs.midi. We can only use inputs.

But I'm glad I found out about SendMIDI, I like it.

 

Me too! When I a bit learning it utility and knew much newest about it:

 

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

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

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 of one, but the direction of impact and results are different between KM vs SM!

 

I had managed to get some result by sendMIDI strings
for Note on/off as "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

Edited March 29, 2023 by vladistone

[vladistone]

After talking to the author gbevin on the discord.com forum. Here is his answer to get the sysex messages via SendMIDI:

Quote

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 encapsulated part of SysEx: `90 64 7F`!

sendmidi dev "ipMIDI Port 1" raw hex F0 00 00 66 10 12 90 64 7F F7

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

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 to equal 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

Edited March 29, 2023 by vladistone

[vladistone]

On 3/27/2023 at 6:20 AM, Jordi Torres said:

Here is getting exactly that behavior orchestrated with the help of a single Hammerspoon (Lua) script:

To be fair the above does rely on a bit AppleScript plus the SendMIDI command-line tool for sending a MIDI command out a specific MIDI port in response to the values gotten from the Compare button state.

The same could be achieved with Keyboard Maestro for those who prefer that tool.

I'll add that ouput redirecting via the LPX environment does work too for the control surface!

But provided that generated messages by KM/HS "doesn't conflict" with the same ports of Logic Control. For example:

- if you have MCU+XT emulation from LPX on ports (1,2) then logic control exclusively blocks other attempts to use these ports by third-party apps, such as when KM trying to send the same SysEx codes to the MCU ... (by the way! This is ignored by SendMIDI, which doesn't know that Logic control "occupied exclusively" those ports)

- and if the controller has additional unused for LC destination ports, then by selecting them in the Logic Inviroment window of the "output module" inspector, you can work through these "free" ports. For example: the SSL nucleus controller has 6 ports, but 2 out of 6 work for MCU emulation, and the rest are switched by MODE / state buttons to the conditionally assigned "DAW2" - ports (3,4); "DAW3"-ports (5,6); Therefore, switching from the default state for the LPX MCU to "DAW3" Port(5,6), you will find your message!

But there is a nuance or call it an inconvenience - in the fragmentation of conditional control surfaces (and feedback too) in a single space ... we will describe it differently, with the example of the "compare" button - in order to find out about the changes received by the controller from the LPX GUI - you need to "swipe page" of the controller surface... or by looking at the PC monitor in the DAW window - to understand what is happening and only then switch to the second mode / controller page - and only there to see a symmetrical signal on the LCD scruble strip or LCD control buttons).

The only drawback of this solution:

- inefficient allocation of controller resources (for example, if you plan to use the "state pages" ("DAW2" or "DAW3") for other purposes (as is CC# emulation or control for peripheral equipment). But it will be up to you... another pleases - no additional "gaskets" between you and LPX are needed (not counting applescript, KM, HS and so on)

 

Edited March 30, 2023 by vladistone