Its on the list. As is OSC.
1 Like
Sounds great! That would make my KM workflows much better! Hope that tomorrow comes quickly 
Another big vote for OSC. I use OSC constantly to communicate with Reaper on Mac via Lemur on the iPad.
Thank you for your fantastic program that so many of us rely on in our workflow.
Any news on implementing OSC? For me it would be such a huge improvement on KM and what it is capable of.
/All the best from Stockholm
Not at this time.
Bummer I’m still hoping for OSC to be implemented. Well, how about the functionality to specify MIDI source or send Keystrokes to a specific program?
Just wanted to check in on this. I know it’s still quite specific, but OSC is getting more and more popular. An integration would the amazing !
Keyboard Maestro will have much more complete MIDI support.
As far as OSC, as discussed the other thread
However, I cannot see how I can use MIDI SysEx constructively. It seems it each device has its own behaviour. I could define my own and use that as a trigger, but how would that be better than the existing MIDI triggers? And how would I send such a packet constructively. There would need to be some language for describing the packet and by that point it would be better done using a third-party tool.
I also looked at OSC and came to much the same conclusion. MIDI has system support in coreMIDI and supports for MIDI over the net, but I can't even see how I would make Keyboard Maestro discoverable. And sending OSC seems to have the same sorts of issues as SysEx - what events would I actually send?
So if anyone wants any actions or triggers related to SysEx or OSC, could you please explain what that would look like (a quick mockup of a trigger or an action would be ideal) and how would it work interoperating with other devices?
OSC seem very specific to devices and packets and so I can't really see how Keyboard Maestro would sensibly trigger or send them. Also, the system does not appear to have any OSC support, and there does not seem to be any sensible discovery mechanisms.
1 Like
I believe that the topic of implementing extended MIDI capabilities has not yet been implemented?
Here is my specific task for using KM:
-
trigger: track GUI changes when Logic pro X (LPX) is running in cases where there is no explicit generation of messages from LPX to the external environment when using MIDI controllers to control DAW (for example: - there is a "compare" button in each FX GUI window)
1.1. when changing any FX parameters, the "compare" button changes its state, which can be tracked using applescript. -
Feedback/Action: The changed state data needs to be sent to the DAW MIDI controller in the form of feedback to turn on the illumination of a certain button - which has been assigned as a doubler for the GUI "compare" button.
2.1 The MIDI controller accepts only Note On/Off, CC#, or Sysex signals for such manipulations. for the first two types of MIDI - a specific assignment of additional parameters is required except for Note on or CC number (namely, the assignment of a specific midiDevice; and midiVirtualPort name) otherwise the message will be sent to all connected peripheral devices! who will react to it differently, .. this is not desirable ...
note: even if a single peripheral MIDI device is connected, it can have several virtual destination ports (up to 6 and higher) that are responsible for different mapping zones.
it is for these transformations that a single application is required that, in its simplified dialog boxes, accepted aplescript and processed the signal in MIDI.
Changing of state cannot be used as a trigger unless the state generates an event.
To continuously poll and application’s state would be prohibitively expensive in CPU and battery.
I don't know what any of that means.
Keyboard Maestro sends MIDI packets, it does not have any support for routing them.
I think you are going to need some sort of other application that deals with distributing MIDI packets to specific devices, that is not something Keyboard Maestro is likely to support.
It can detect packets in any form sent to it, and it can produce packets and send them out, but it does not direct them once they are sent.
Keyboard Maestro sends MIDI packets, it does not have any support for routing them.
I tried this method, but the KM splits SysEx message into 3 parts:
for example: F0 00 00 66 10 12 90 64 7F F7
12:39:43.200 From Keyboard Maestro SysEx Loud Technologies / Mackie $6 bytes F0 00 00 66 10 12
12:39:43.200 From Keyboard Maestro Note On 1 $64 $7F
12:39:43.200 From Keyboard Maestro Invalid $1 bytes
The last invalid message byte is F7 - EOX
Thus the second message is intercepted by LPX and everything else is discarded as unreachable.
Maybe the "send raw packets" syntax should be somehow strictly defined for SysEx messages? Since the above behavior of KM when sending MIDI packets is very strange. Otherwise how to understand the logic of sending SysEx messages? Which must be a single sentence/phrase enclosed between F0 ... F7 according the rules of MIDI!
Keyboard Maestro sends the bytes as a single packet, so I don't know why or who is breaking the bytes into parts I'm afraid. The code used to send the entire packet is:
MIDIPacket* p_head = MIDIPacketListInit(pktlist);
MIDIPacketListAdd( pktlist, kMIDIPacketListSize, p_head, 0, len, data );
MIDIReceived( gMIDIEndpoint, pktlist );
It is a single array of bytes. So whatever happens to break them up happens after it leaves Keyboard Maestro code.
I wouldn't say so if it weren't for the facts provided by MIDI Monitor app.
try to send my message yourself:
F0 00 00 66 10 12 90 64 7F F7
and monitor the result of sending, and not the reaction to this message (since you don’t have the device that the Sysex message refers to ... it’s simple: the message must to pass unprocessed with anything) If you get the same result, then it’s not MIDI the monitor breaks it into 3 separate parts, and KM faults
I think you'll find it's the 90 in your sysex that's causing a problem. Change it to 7F and it's OK. This shows a successful message (with 7F) followed by an incorrect one (with 80):
I'm no expert but have dabbled...
1 Like
90 - is the MIDI code that defines the call to "Note On"
it's not my whim - but the construction rules/syntax if you want from MIDI!
and Can I see from judging by your screenshot, you have the same reaction of KM to send Sysex - which you considered the same MIDI monitor app.
therefore - this is not my local problem! and the global one is the culprit - KM
KM is sending, and MIDI Monitor is receiving, the entire packet.
If you look at MIDI Monitor:
...the first line shows the "wrapper", the starting F0 00 00 66 10 12 end the final F7 (EOX). So the command to be interpreted is 90 64 7F.
I'm no MIDI guru (and have just seen I'm arguing with @tiffle -- believe them before me!), just playing around with MIDI Monitor, but 90 appears to be "note on, channel 1" (89 is "note off, channel 10" and 91 is "note on, channel 2", so that seems reasonable). 64 is the actual note, E6 (again, as a sanity check, 63 is D#6 and 65 is F6). It's 7F that's the problem.
Go to the documentation for whatever and review the codes you should send -- that's where the problem is.
1 Like
I know all this... and the same penultimate byte 7F - value of velocity as 127 (max note-on sound). there is no mistake ... you are wrong ...
especially - MIDI monitor only reads transfer information without embellishment or transformation... my other programs - react the same way to this output message - single note what have to sent to Loud Technologies / Mackie $6 bytes with Sysex start: F0
00 00 66 10 12
only logic pro sequencer is intercepted! although last sysex part is not intended for this app:
90 64 7F
but work properly
next coda or EOX: F7 - losted without header Sysex F0
Sysex tutorial
Learn the rules for building a MIDI Sysex. they are not complicated like 2+2=4:
head part F0 - is inseparable from EOX - F7 and includes assignments - manufacturer's name ID & device model ID: 00 00 66 10;
further command "send/transmit": 12 and message argument - 90 64 7F
Then we're both wrong -- MIDI Monitor is showing that KM is atomically sending the packet as instructed (or do you think Monitor pulled that trailing F7 out of its magic hat?).
But I might have a solution (hopefully @peternlewis has an explanation!) for you. After some playing around, try without including the EOX in the raw packet:
...which MIDI Monitor shows as:
@peternlewis -- that behaviour feels a little odd to me (although I know next to nothing about MIDI). If the velocity value is omitted then the EOX is required in KM's "raw packet" field, if velocity is included the EOX must be omitted? Rather confusing for a newb such as myself! Or is this an interpretation, rather than an output, issue?
People are being rude in this thread so I will be closing it.
If people want to start another thread on the topic, they will need to commit to being civil in it.
As I have said, Keyboard Maestro coverts the text in to bytes and sends the bytes as a single packet with a single API call. What happens after that, I have no clue. Whatever is to blame, however it is interpreted or misinterpreted, Keyboard Maestro has no ability to change.
If you want different results from the action, you will need to use different bytes in the raw packet.
2 Likes