Why not just create another group that is all apps except LR?
Or, move the Macro with X trigger to any other group that does not include LR?
How often does this use case come up?
Seems to me Peter has given us all the flexibility we need. 
Why not just create another group that is all apps except LR?
In my original post, I pointed out why that won't work: Because, as I noted, that disables all those macros in LR.
I have a keypad with 18 keys devoted to macros. I have keys 7, 8, and 9 (for example) devoted to cut, copy, and paste. I want those there all the time. (Muscle memory, you know...)
This is one of those things that, thinking about, seems simple enough to resolve. However when you actually try to DO it, the gotcha's crop up.
From a programmer's perspective, (AND if there isn't some simple way around it that I've just missed) it is FAR more simple to have "default" and "over-rides" than requiring a complex set of includes and excludes in at least two different groups, to achieve the same effect.
Frankly, if one has an app-specific key/trigger, I'm having a hard time imagining a case where -always- forcing a popup choice is, in fact, the most commonly useful result. One would think if you've made a specific macro for a specific app, that is the one you'd want to run. If you really want a choice, I'd append a universal "show-me-the-popup" modifier key.
How often does this case come up?
For me, extremely often, as I have a number of those keypad keys I want to keep working the same, regardless of app. So often that having to add to a list of in-place specific exceptions is now tedious, confusing, and error-prone.
I most frequently run Photoshop, Lightroom, Final Cut Pro and Rapidweaver. And in each of those cases, I want some, but not all of my keypad to perform app-specific tasks using a single keypress on the keypad. Groups gets me part of the way there, but everytime I add a new app, and hence a new group, I -also- have to go back to all the other groups and fiddle around with their settings (generally adding an exception for the new app) to avoid the popup.
The whole point of macros is to make life more simple, and an unnecessary popup defeats that purpose.
I expect that Peter has either considered this, or intended this, but right now, as it stands, it is all far more complex than a simple "app-group overrides default" would be.
Maybe it's a preference I've overlooked, or some popup I've chosen incorrectly (however, if that were the case, I'd assume someone (you?) would have mentioned it.) Programatically, it's not particularly difficult to do (avoid the default) unless there's some hard-wiring in there that makes it so.
Seems to me Peter has given us all the flexibility we need.
I could reply three ways: 1) yes.... perhaps too much, or 2) almost, but missing "front", or 3) way too much if the generic override was implemented.
Hi. I didn't read all of your post, but I think I might have a very acceptable solution for you:
Create a "master" macro in the Global Group Triggered by Hot key "X"
Remove the "X" trigger from all other macros.
Then in the macro test for the front application.
IF Front App = LR, THEN execute sub-macro for LR
ELSE execute the global macro you have now.
This way you have ONLY one macro with a trigger of "X" that will behave exactly as you have requested.
What do you think?
Good starting thought, and that would work. But it jumps right back into the “lots of modifications” issue.
It would be more “intuitive” to have a group simply over-ride a global, at least to me. To be sure, in either case, I’m still adding macros of approximately the same size, using your suggestion or mine, but with many apps, I do end up with
IF Front App = LR, THEN execute sub-macro for LR
ELSE IF Front App = AA execute sub-macro for AA
ELSE IF Front App = BB execute sub-macro for BB
ELSE IF Front App = CC execute sub-macro for CC
ELSE IF Front App = DD execute sub-macro for DD
ELSE execute the global macro you have now
which gets quickly unwieldy too.
The other possibility is to duplicate the global group into an app-specific group, and then change only the ones I want different, and lock out the global group, but that messy too.
I swear there has to be something I’m missing here…
thanks for the thought !
Thinking about it as a programmer, here’s what I’d do:
There has to be an entry point for each activator (well, at least keys) that checks to see if there’s a conflict, and puts up the conflict pallet.
I’d put in a preference that just toggles at that switchpoint. “Use Conflict Pallets?- checkbox"
Then insert “if globalUsePallet” continue check, else (if not globalUsePallet, then use app macro.”
Assuming there’s only one such entry point, then the code would be trivial to implement (at least in theoryl… 
Help me understand this: Why do all of these different macros for different app have to have the same trigger Hot Key AND be in the Global Group?
Any time you want to automate a task, you have to consider the effort to create the automation vs the frequency of use.
In all honesty, your use case seems like a real edge case, that has a number of very workable alternatives with the existing feature set. 
Obviously Peter can decide if he wants to expend the effort to support such a use case.
IAC, you have a number of very acceptable (IMO) approaches if you want to get something done now. Who knows IF/WHEN Peter will make the changes you want.
A couple things. A macro group can be available in specific applications, or available when specific applications are running. You rarely want to use the latter option unless you want to set up, say hot keys for a specific application that are available whenever that application is running. Normally you want application-specific macros only when the application is at the front. So make sure you are using the right configuration. This is yet another example where adding configuration and options adds complexity and ways to go astray.
I covered some of the design methodology in excruciating detail in a similar post recently:
So start by reading that message, because a good understanding of my basic "why" of design will inform on why I make decisions the way I do.
I get this question about why application-specific macros don't override global macros regularly, but (almost?) invariable from folks who have used Quickeys which works this year. However, Keyboard Maestro has never had any real concept of macros that are "more global" than other macros. The only reason for the Global Macro Group's existence is that there needs to be somewhere really global that macros get created when no macro group is selected.
I chose in Keyboard Maestro to make use of conflicting trigger keys in a very powerful way which allows you to use a single key to perform a range of related activities very simply and this works really well.
Certainly it is possible that I could adjust Keyboard Maestro such that if a macro has two conflicting hot keys, then instead of using the Conflict Palette, Keyboard Maestro could pick one for you based on the one that is "more specific". But then we immediately get in to complexity because Keyboard Maestro has many different ways that a macro can become active:
- Enable/Disable the macro (manually or via a macro action).
- Enable/Disable the macro group (manually or via a macro action).
- By activating or deactivating a macro group (manually or via a macro action).
- In some specific set of applications.
- Outside of some specific set of applications.
- In some specific set of windows.
So then we have all sorts of edge cases. Is a macro that is specific to Lightroom more or less "global" than
- a macro that is specific to a titled window?
- a macro that has just been explicitly activated?
- a macro in a macro group that was just toggled on for one action?
There is no good answer to these questions.
Now, it is possible I will add in either the behaviour or the option to say:
- If exactly two macros conflict with a hot key
- And they are in different groups
- And one is in the Global Macro Group (or perhaps any group that is entirely global)
then execute the other macro without the conflict palette.
But such special cases go against the design of Keyboard Maestro, which is why I have not done them, despite fairly regular requests from Quickeys refugees. Such cases are relatively infrequent, leading to either a few macros that behave differently in different applications, or a few groups with names like "Not Lightroom". Both of which are easily done in Keyboard Maestro, although Keyboard Maestro tends to be "more verbose" than Quickeys, but that is not necessarily a bad thing - being more verbose and more explicit, while using simpler concepts is part of what keeps Keyboard Maestro's complexity down.
In practice, its probably good to generally avoid a frequently used hot key globally that you then redefine to a completely different purpose in a single app. And if the purpose is to have a globally defined macro that needs to vary its behaviour in one application, then adding that variation into the global macro makes sense as well.
So that's the reasoning.
1 Like
VERY helpful to understand your reasoning (at least programmer to
programmer) and I thank you for that, Peter.
I’ll admit to being at least moderately relieved that there wasn’t some
bone-headed thing I overlooked vis-a-vis settings, and the “issue” as
such was “real.” It’s also reassuring that you’ve gotten this “a lot” -
so at least I’m not alone.
I can understand better your choice now that I understand the paradigm,
and I’ll just have to work around it. I did note that I too am a
QuickKey refuge, and that was certainly part of the genesis of my
question.
I’ll go back and read everything again, including your suggested post,
and figure my way around it.
(I also want to again thank you for your help on getting the Corsair
Keyboard programmable G-Keys up and running. I do hope it has been of
some benefit to you and at least some of your customers.)
Tracy
www.valleau.gallery
1 Like
Hi again. :No doubt you’ve read Peter’s response by now, so much of this is moot, but to answer your question: I have a $230 keyboard that has a programmable macro keypad of 18 keys off to the left of the main board. It does not work natively with the Mac, and Peter was kind enough a few months back to get it working with KM.
The point here is that 1) there is a keypad and 2) it has only 18 keys. That keypad allows me to press a single key, without requiring a modifier key. So instead of command C, I just press the G8 key. You might think single key vs double key is trivial, but when you’re editing photos or video, you are often using that macro hundreds or thousands of times at a sitting. The single-key turns out to be extremely important, and significantly faster.
In FCP and Photoshop and Lightroom, there are literally hundreds of shortcuts, not to mention the sequences that I create for my own workflow. In each case I have to pick out the 18 or less that I want on the keypad. Yet keeping Cut, Copy, Paste on G7, G8 and G9, Illuminated with a different color for just those three, is useful regardless of the program that is running. However, in Photoshop, I want to select the next or previous blending mode with a single key (instead of the default 2-key shortcut) so I’ve dedicated G13 and G14 to that. I can quickly cycle through layer blending styles looking for a blend I like. I don’t need that anyplace else, except in PS. Otherwise those keys are used activate Liquid, and perform a Google search (neither of which I need in PS.)
This all comes down to workflow, and my own preferred way of doing it. Having used macro programs for over 25 years now, I’m pretty darned familiar with what they can and cannot do, and how much energy it takes to make a good, bullet-proof one.
After reading Peter’s reply, I understand what he’s up against. After repeatedly being told that mine “is an edge case” on the one hand, and Peter being asked the same question “regularly” it’s hard to reconcile those two. Either a lot of people think it’s a good idea, or it’s only me.
I’d suggest the evidence indicates that it’s useful to more than just me.
That said, it’s Peter’s software, and it works the way it works, and so be it.
It’s not my intent to argue, cajole or belittle. I used to write this stuff for a living. (I was the first non-employee programmer Apple ever hired, in 1978, and I’ve been at the keyboard ever since. Making suggestions that I feel might better a product is what a good customer does. Whether I’m right or wrong; whether the idea is accepted or not, is an entirely different matter.
That said, I stand by my suggestion, and appreciate the courtesy extended me by one and all during this exchange.
2 Likes
Thanks, Chris. Based on Peter’s reply, perhaps I had the wrong criteria selected, although I thought I’d checked them both. I’ll admit that the distinction between:
“available in a specific application” and
"available when specific application is running"
is more than a little vague.
If the application has not been launched, then I’d expect that "available in a specific application"
would not allow triggering. But if it has been launched, then by definition it IS running - either in the background or in the foreground, but either way, it is running.
So I took “is running” to mean “is in the foreground.”
So: I have a global macro on G17 that toggles the display of a Dragthing dock.
I have a group dedicated to LR where G17 toggles the second display on or off.
When LR if frontmost, G17 simply toggles the second display, as it should.
However… when I click on the desktop, and thus LR is no longer in the foreground (the finder is) and I hit G17, I get a popup menu asking if I want to toggle the second display, or the DT dock.
So obviously “running” does NOT mean frontmost, it mean just what it says: running, foreground or background.
Based on Peter’s explanation just now, I switched to “available in a specific application”
(without the “running”) and that seems to have fixed my issue with that particular combination.
I’ll play with it some more tonight, and see how it goes.
Again, my thanks to everyone.
Hey, Tracy. Feel free to ignore this. You're probably tired after all the discussion.
I am trying to both understand, and hopefully give you some ideas/workarounds. But it's totally cool if you just want to move on at this point.
So,I read your post several times, and I still don't get why you can't create a setup like this:
- In the Global Group, create macros with triggers of your keypad for all the shortcuts common to all of your apps. For example, assuming CMD-C does a copy in all the apps, but you want to map that to G8.
- Create a Group for each app (available ONLY to that app) to hold the macros unique to that app. For the keypad keys that are different for each app. This allows you to have a unique keypad mapping of the same key for each app, without any conflicts.
This should work and not generate any duplicate/conflicting macro popups. I would also think it would be easier to maintain since you know exactly where to go for common macros, and for app unique macros.
Maybe I'm missing something about your setup, but it seems to me that should work.
If you'd rather just move on at this point, I totally understdand.
OTOH, if you'd like to discuss more, I'm willing if you are.
Best Regards,
JMichaelTX
Thanks again.
I still don't get why you can't create a setup like this: (snip)
Actually, that's exactly what I've had all this time, and exactly why I
posted in the first place !
But because of the confusion between
"available in a specific application" and
"available when specific application is running"
I was getting popups I didn't want.
See my reply to ccstone.
I'm going to check into this further, (for example, one thing I'm
checking is to see if a -disabled- key in an app group, affects the same
global key, or does the app key need to be completely removed...?) and
if something else comes up, I'll continue.... but for now, I think I'm
good.
Thanks again.
Tracy
www.valleau.gallery
I do this a lot. I have 8 groups that specify "Available in these applications" with only 1 app selected, like this:
I have never had any trouble with macros in one of these groups showing up as available in other apps, and, the macros are always available when the app is the frontmost app.
The key: "Available" means when that app is the frontmost app.
No conflicts, solid as a rock. 
I hope this helps. Try it!
Yep. That is absolutely correct. As I said, I had chosen “available when
specific application is running”
Tracy
www.valleau.gallery
That's probably why you were getting the conflicts and popup.
You need to choose "Available in these applications".
Then the macros for a specific app group have no effect when other apps are frontmost. You don't have to worry about enabling/disabling the macro to keep it from showing up in other apps.
Tracy,
I totally get your quest for “one key actions”. I have been eyeing this keyboard for Pro Tools… http://dnamusiclabs.com/hotkey-matrix
It’s already got all the keyboard shortcuts mapped for a majority of functions and with your post I can see where it might be handy to setup some additional keys. I am curious. Does KM see the additional keys without a lot of additional setup?
The bummer about Computerdom is that eventually we need to find replacement programs for programs that have reached end of life/end of OS support, or a developer ran a One-Man-Show and decided to throw in the towel e.g. What happened with Now Up To Date/Contact. (I am thinking OS 9 days here as far as OS). Hey I loved my OS 9 workflows, don’t take them away! Heh! Anyway don’t apologize, I am glad you asked the problem. It gave Peter a chance to mention some stuff that I found very enlightening. That wouldn’t have happened if you hadn’t asked the question.
Cheers!
Hi Tunes
No problem finding my extra keys. I chose “This device key:” from the popup trigger menu and then just tapped the key I wanted to use. Tip: also click “with these modifiers”. then if you don’t want any modifiers, just leave them off. This is NOT the same as “ignore modifiers” which caused me some confusion a while back.
(Yep: I remember “Now Up to Date” too…)
Another approach is to have one group that is or is not operative for a group of applications and another that is for all applications. I use a lot of function key bindings (with lots of modifiers), but so do development environments and editors I use. I have two groups, one available for all applications and another available except in Terminal, Emacs, Xcode, X11, VirtualBox, and some development environments.
Thanks for the suggestion. That’s exactly what I’m doing. I appreciate
your thoughts.
Tracy
www.valleau.gallery
Might using Quadro (https://www.quadro.me) on an iPad positioned beside your keyboard be helpful? It seems the keypad’s 18 keys bottleneck is forcing a degree configurations that would be eased by have more physical switches within usable range.