I have this Pause Until action that stalls on my Big Sur system where is runs fine on High Sierra.
I have a pause until menu item is enabled. But when I observe it, is shows FALSE when it is actually TRUE.
So I inserted a new action, the same, and made the same settings. And there is shows TRUE.
How could that be?
Then I thought; well maybe a 'broken' action but the first time the loop in the macro runs it is fine but a second time it runs in the loop I get a reverse result; it shows TRUE where is should be FALSE
Could it be that somethings interferes with KM?
The program I use the macro in is Avid' Pro Tools.
This isn't very helpful, but I am recently experiencing a similar problem intermittently with a macro that had been working flawlessly for years. I am still troubleshooting, but my situation is very similar in that I tried creating a new macro with an identical Pause Until action that does recognize the active app, but when I go back to the original macro, it also recognizes it again. Hopefully I can isolate it one of these times and report back.
Yes, I did. But it will get stuck after one or two runs of the macro.
But I am getting somewhere.
There is another set of five macros active and when I disable that group it is ok.
These macros are listening to a stream of midi and the macro's are triggered by some of the MIDI channels. I cannot control this stream as it is generated by a device that I cannot control. My suspicion is that KM is getting overpowered by this stream and has no resources anymore to make this Until Menu Path work. Although these macro's only have only a few simple actions, I still think the high frequent triggering is a problem for KM. With high frequency I mean approx. 11 midi messages per second that KM gets and approx. 6 times per second a triggered macro. maybe that is too much for KM.
Here is the stream as document.
The midi stream. Colored items are midi messages that I have a trigger for.
Can you post one of your midi macros and describe what you're trying to do with it? There may be a better way to get there than constant triggering.
As an aside, if you're using midi as a trigger, you may find the midi macros here of interest:
As part of the long-press detection, the "Detect" macro (which watches for all midi traffic) is only activated after a specific midi message is received. This gets around the problem of KM having to deal with endless midi data.
I can post them but it first will explain a bit. ( they are on another computer will post them later if you like)
The audio edit and mix application Pro Tools has the ability to install a driver for a real fader and button surface, called the Mackie HUI. (human user interface). It communicates to the computer, to Pro Tools, through MIDI. When i press a button it sends TWO midi commands to ProTools and ProTools reacts to it. And in reverse; ProTools sends midi commands to the HUI to make LED's light up (or off). And also here; for each button or LED it uses TWO midi messages. It is like a table with rows and columns. The first midi message opens a row, the seconds tells the column and the crosspoint of these two is the LED or the button.
Here is the table.
I don't use this actual surface device, i use only the driver and KM will emulate this surface,.
The buttons are easy to emulate. I just make a macro with two midi actions and i am set. Works perfect.
But the other way round; trigger KM when a LED on or off is send is a real challenge.
Because i have to make two macro's. One is for the 'rows' and enables a variable that the specific row is opened. In the above log you see that for midi command 12-25 for example. I have a macro that just sets a variable to "ON" when MIDI command 12 -25 is received.
The other macro reacts to the to 'column'. It triggers on midi command 44 -67. But the action in this macro will only run if the variable for trigger 12-25 is also on.
In practice it means that these macro's are very frequently triggered. Only when a combination of the two are received in a row, they resume the macro. Else, the macro stops.
I have been fighting with this for like a year, and i have it finally working because it is very tricky how to set these triggers and variables because of this high frequency. I have not found a way to filter unwanted triggers out or filter the midi stream without making another complex routing with third party apps.
Not really sure what to suggest, as I'm sure you've been a long way down numerous avenues. I had a quick look at Midipipe, but it doesn't seem to do range filtering for CC numbers or values.
I'm sure you've already looked at this. Apparently you can "configure... the range of the first two bytes". I'm not sure if that's at all relevant, but thought I'd flag it just in case.
Perhaps you could have individual triggers for each trigger in each of your two macros, but that's incredibly clunky. This is a bit beyond me, so sorry not to be of more help. Good luck!
Thank you for your input NoisNeil. Really appreciated. I also tried Midipipe, with the same conclusion as you made.
Maybe, to release KM from some strain, I can rebuild the whole macro set somehow in ControllerMate. But that's going to be a challenge. First because KM is better and easier, second because CM is buggy in BigSur. With some tricks I got it installed but the saving of the profile failed and I had to use a text editor on the plist to cure it. I am not looking forward to do this all the time...
Out of interest, if you're not using a HUI controller, what are you using to reflect changes made in PT? Is this just to set states in KM so it knows the state of various buttons or are those changes visible on a Stream Deck or other such input device?
The start of the need was that I want protools to trigger KM. Not me triggering a Stream Deck button or whatever.
So, what I do to accomplish this, is I fool protools by telling it there is a HUI connected. And I tell protools where to send the MIDI to. I use an internal midi decide for it, an AIC. And, then I make KM listen to this AIC.
Now, when click on something in PT that would illuminate a led if I had a real HUI connected, it would now trigger KM.
And yes, with this trigger I can make LED's on my XKeys on or off, or make them blink. or I could indeed set a stream deck icon. Or set a variable that other macro's can use.
BUT
For the few hours I tried to rebuild these macro's in ControllerMate and it was much easier then I thought it was, the first tests tells me. I have to do some more testing to prove reliability but it is promising at this moment.
I've put in a a fair bit of time trying to automate Logic Pro, but I never even considered looking into HUI as I assumed it was a closed system. I can't think of anything I'd want to do that would require it, but it's going to be at the back of my mind now!
