vladistone

That's why I was puzzled in search of a workaround for triggering the value of this control area. Have you any ideas? and according to my version of LPX 10.4 - I have the impression that the change tracking synchronization by compare_buttons between the smart control windows and the window FX / AUi dialog itself with which the smart mapping is created is out of order!

yes, I ment that text area... so sorry

Hi @Jordi Torres You did discribed how to get parameter value the dialog windows. but I loocking for the smart control area button, which haven't this "value" (see pic.)

Maybe another way? - is to try to resolve the AMS configuration file. but that's not my area of expertise... Does anyone have more advanced experience and ideas for configuring ASM elements? see preferences AMS window:

AMS items can be forcefully removed from the system, but they are returned when reconnected 🤔 Creating multiple AMS configurations as a way to reserve the LPX physical inputs of the MIDI environment does not guarantee that they will actually be connected at the present time and are identical connection order (its including the time of the power-up sequence and including in accordance with USB ports order too), although this reconstruction is better implemented than into WinOS - there the leapfrog with reserved and phantom ports is more problematic... The only thing that can solve the problem of reserving ports for switching devices is an external USB / ethernet MIDI hub such as iconnectivity mio10 or mioXL which has the ability to reserve ports for a specific ID-device! But then the whole point of a virtual MIDI router discribed above VS physical USB/MIDI hub is lost!

Hi @Jordi Torres ! Do you know how to get the state value of the GUI object?

Finally, I managed to assemble a single applescript for adequate interaction from GUI LPX events (in this example, the "Compare" buttons for smart control) to the MCU controller with SysEx and Note On transmission via Send MIDI. I had to tinker with the problem of quotes that needed to be passed on the terminal command line for the ipMIDI port. maybe not the most elegant solution in applescript coding?! And does anyone have any more interesting ideas on how the LPX Events GUI interacts with the virtually only 3rd party Send MIDI application. knowledge sources on terminal command line via applescript shell script global smartControl_panel -- global variables are available everywhere in the script global compare_button global compare_state global portList global portChoice global gportName set gportName to "ipMIDI Port 1" -- reconstruction of returned message from command line "sendmidi list" set portItem to (do shell script "/usr/local/bin/sendmidi " & "list") set portString to findAndReplaceInText(portItem, " ", ", ") on findAndReplaceInText(theText, theSearchString, theReplacementString) set AppleScript's text item delimiters to theSearchString set theTextItems to every text item of theText set portList to theTextItems set AppleScript's text item delimiters to theReplacementString set theText to theTextItems as string set AppleScript's text item delimiters to "" return theText end findAndReplaceInText -- assigning a MIDI port in the dialog box set portChoice to main() on main() try set portChoice to (choose from list portList with prompt "Which running MIDI-port?" with title "Choose a MIDI-port of destination") if (portChoice is false) then error number -128 try set gportName to "'" & item 1 of portChoice & "'" on error error number -128 end try end try end main -- identifying GUI changes tell application "Logic Pro X" to activate delay 2 tell application "System Events" tell process "Logic Pro X" tell window "task 1 SSL setup 22 jan 2023 - Tracks" -- you will have to specify your own project name to restore the script to work (* the following lines find the smart control panel, by looking for stable features of their respective toolbars. the first looks for the 'Compare' button, the second for the 'Arpeggiator' checkbox. the doubled 'whose' queries look confusing, but basically they say "Find the group whose first group is a toolbar, whose last (slider's/radiobutton's) description is... Once we have those, we can reliably find these area, regardless of whether other groups are opened or closed" *) try set smartControl_panel to first group whose its (first UI element whose role description is "toolbar")'s last checkbox's description is "Arpeggiator" on error -- if smart control panel is not open, so open it by LPX key-command keystroke "b" keystroke "b" delay 2 set smartControl_panel to first group whose its (first UI element whose role description is "toolbar")'s first button's description is "Compare" end try tell smartControl_panel tell first group -- log a list of all the visible UI elements log (get description of every UI element) set compare_button to first UI element whose role description is "button" and description is "Compare" -- log current state of the compare_button log (get enabled of compare_button) set compare_state to compare_button's enabled if compare_state is true then (* tell application "SendMIDI" to activate with raw sysex string by command-line of terminal; or Note_on message which were add at end of that string too, see step after EOX 0xF7 *) do shell script "/usr/local/bin/sendmidi" & " dev " & gportName & " raw hex F0 00 00 66 10 12 00 43 6f 6d 70 61 72 65 F7 90 52 7F" -- do shell script "/usr/local/bin/sendmidi" & " dev " & quoted form of "ipmidi port 6" & " raw hex F0 00 00 66 10 12 00 43 6f 6d 70 61 72 65 F7 90 52 7F" -- another action option - click the Compare_button to toggle its state click compare_button end if end tell end tell end tell end tell end tell

Hello @des99 did you dig into OSC protocol? how your result?

would you to demonstrate your code?

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)

After talking to the author gbevin on the discord.com forum. Here is his answer to get the sysex messages via 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

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

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.

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