Hello, just for future proofing my system, I need to setup 84 macro groups that will be mutually exclusive, only one macro group can be enabled at a time. Which one if activated comes from midi CC messages.
As I don’t know how to setup a mutually exclusive feature, I am forced to hardcode 84 disable enable for each of the 12 macros. So 1008 blocks of enable/disable, and I am wondering if there is way to not break the macro in case some day I rename the macro groups. Which will probably not happen but you never know
The link will be maintained, even if you rename the group being enabled/disabled by the Action. The Action will simply show the new name of the Group. Try it and see.
When you create a Group it is given a name and a UID (unique identifying number). This allows two groups to be given the same name but still operate correctly. It is this UID that the Action is linking to.
That is an unusual way of operating and I am not going to guarantee that you wont running in to some issues.
I presume you are not expecting to have this MIDI CC messages come in at any kind of high speed because if you are it’s quite possible you will run in to problems.
Macros or Macro Groups? I’m confused now, are you enabling/disabling macro groups or macros?
Renaming macros or macro groups will not break a Set Macro or Group Enable action. They are identified by UID, not name.
Maybe step back and explain what you want to accomplish rather than how you want to accomplish it (see XY Problem)? What you are describing sounds like an unwise way of using Keyboard Maestro.
I use Helium (a floating, always-on-top browser window app) to display this value in real-time. Helium loads a local HTML file that continuously reads scale_degree.txt and displays the current scale degree in large text on screen.
Result:
The complete chain — MIDI Note → KM Trigger → Variable → Shell Script → Text File → Helium Display — lets me input notes one by one and instantly see which scale degree they represent. Currently working perfectly.
Current Development:
I'm now building a scale switcher macro that will control which of the 42 macro groups is active (only one needs to be active at a time). I'm using MIDI CC messages from my Stream Deck to select the musical scale, which will enable the chosen macro group and disable the other 41.
As you have been told, you don’t have to worry about renaming macro groups. This is handled automatically by KM.
Your latest detailed post explaining the problem may help others determine if your approach is non-optimal. The idea of needing over 1000 actions to implement anything in KM seems like it may be non-optimal.
I write lots of large macros with lots of “dynamic context problems” and I usually solve these context issues using large Switch actions instead of using macro groups which are disabled and enabled. I also use “State” variables which tell my macros, including my Switch actions, which block of code to use. Just last night I wrote a macro with probably 1000+ actions that seems to work 100% perfectly (to my great surprise), and it uses these approaches. If your macro works perfectly, maybe you don’t have to change it, but in the future you may want to consider variables that save context in such a way that your macros do the appropriate thing using those variables rather than enabling/disabling macro groups.
I think you might be able to do this within a single macro. Perhaps you could set it to respond to any MIDI note, set the key and scale via global variables and use your shell script to return the intervals.
I don't think this has been mentioned yet, but it will be a lot less work to make a Subroutine that disables all 84 Groups (even though only one might be enabled), then each macro would
Call the Subroutine, disabling all the Groups
Enable the specific Group(s) you want
It shouldn't be too much of a speed hit to do those "unnecessary" disablings.
But I think @noisneil's onto something -- unless the Groups you want to control contain other macros that must only be available when you are "in" a particular scale degree?
If all your shell scripts are doing is echoing out your ScaleDegree variable, I think it will be slightly faster to use the KM "Write to File" action -- no shell instantiation overhead:
