That's interesting! I'm gonna try that out myself!
1 Like
I tried it on my end and it didn't work but I understand why after looking inside the Stream Deck editor.
I think this explains it. Running it in the background doesn't switch the stream deck profile as it requires the app to be in the foreground for at least a split second.
Too bad.
I suppose you could have the applet:
- Disable the switch macro on launch.
- Activate itself.
- Activate Logic Pro.
- Re-activate the switch macro.
- Quit itself in the background.
I think that might work, and it should still be quite fast.
-Chris
I did find something that breaks the loop and posted it above that should solve Neil's issue. I liked what you had cause it was so streamlined and clean but unfortunately Stream Deck had other plans in mind. Hopefully they will update soon and the ability to switch profiles can be added as a dedicated feature within KM but who knows!
1 Like
@ccstone, thanks for the suggestion, which was along the same lines as what I was trying. The trouble was the enable/disable states were sometimes not switching back properly.
@ncbasic, your suggestion works, but only when Logic has an open window, so I added an "Activate Logic Pro" action and all seems good!!! Thanks!
TL;DR: can you stop a macro from executing if it (or another specified macro) ran within the last few seconds?
Ok I have a new issue...
Just to complicate things, I also have SD profiles that trigger based on the currently open plugin window. I have a dedicated SD button that OCR scans the open window, then opens the corresponding blank app that triggers the profile. Trouble is, when the plugin profile has been set and focus returns to Logic, it triggers our macro to switch the profile to Logic, so in effect it breaks my plugin profile triggers.
Perhaps there's a way to disable the Logic profile trigger if the plugin profile trigger has just run, within say the last 3 seconds? This, incidentally could be another way to break the logic profile loop, assuming it's possible at all...?
Maybe this is relevant here? Condition for whether a macro is being run from within another macro - #3 by JMichaelTX
...or @ccstone's contribution here?: MACRO: Get Recently Run Macros with Last Executed Time - #27 by ccstone
Yeah I was playing with it some more as I noticed it would leave Finder in the front so I came up with a similar solution!
Well is it's possible. There are probably better ways than I am about say but I still consider myself an amateur in this arena... music production is my expertise. My solution would be pretty much the same concept with the variables in that they will be used to tell the macro where/how to run.
If you create a dedicated macro to set a variable, pause for 3 second, and the change or delete the variable you can reference that in your workflow where need without have it pause the macro you're using. Of course you could use the same concept by disabling the macro... kind of depends on your needs.
You could use a global variable like LP_DoNotRun`
Your main macro could start with an IF LP_DoNotRun = TRUE then Don't continue
Set the global variable to TRUE using a asynchronous sub-macro with a timer, and set it to FALSE when the timer elapses.
-Chris
Blimey. I'll have to spend some time thinking about this as some of the concepts you're using are new to me.
In the meantime, this janky solution is working (I think!). I'll really try and get my head around what you're saying though, as I can imagine a few other scenarios where macros could clash and a dedicated macro to avert that would be very nice!
1 Like
Ok so I think I understand. Maybe...
Here's the main macro:
...and here's its sub-macro:
I'm not sure I understand the reason we're using a sub-macro rather than just including it as part of the main macro...?
Having it as a sub-macro means it can run asynchronously to the main Macro. (And you have to set the asynchronous option using the gear wheel in the Execute Macro Action - which I can see from your screenshot you haven’t done yet).
If it is a sub-macro and runs asynchronously to the main Macro, the main Macro will continue to run while the sub-macro also runs.
If it it were a part of the main macro (i.e. not a sub-macro) then the main Macro would stop and wait until this part had run.
Hope that helps! I’m sure @ccstone can explain it better!
I see. So if I had further actions within that macro, they would have to wait for that 1.5s pause unless the loop-breaker sub-macro was asynchronous. That's clever. Thanks!
Maybe I'm mis-understanding what's going on here, but wouldn't you be better off (in this case) simply associating your StreamDeck profile 1:1 with Logic?
skipping the 'launch an app to trigger the profile' trick here altogether?
Hi @johns,
Yes, that would be the case ordinarily. However, if you want to use @ncbasic's idea to use blank apps to trigger profiles, you don't necessarily want Logic to automatically trigger its associated SD profile every time it comes into focus, as that undoes the manual trigger you'd just run.
Does that make sense?
Thanks to @ncbasic and @ccstone, my SD now displays my Logic profile when plugin windows are not in focus. If I click on a plugin that has a dedicated SD profile, it loads it; if it doesn't, it loads my generic plugin profile that contains common controls. This is all in the service of being able to use my nObcontrol with as little time looking at the screen and as few extraneous button pushes as possible... so far so good!
Here's where I got to. Attached are the two profile trigger macros: one for Logic and one for plugins. Also included are the two loop-break sub-macros.
The only minor drawback is that, due to the loop-break pauses, profiles can't trigger in quick succession. If, for example, you click on one plugin and then another within the pause duration (which is necessarily 1 second or longer), the first plugin's profile will persist. Then it's a case of clicking back and forth until they work themselves out. I can live with that, but if anyone has a eureka moment and can think of a way to avoid feedback loops without pauses, do chip in!
Logic - Stream Deck Profile Macros.kmmacros (21.4 KB)
Also, if anyone knows how to make a bunch of exceptions for which windows won't trigger the macro without a giant list like this, that would make the macro a lot easier to look at. After reading this, I tried adding them all to one entry like this: tracks|mixer|event list|preferences|edited ...but it didn't work. Again, a minor complaint.
I've been trying (and failing) to set up a window blacklist but I think a neater idea might be to detect whether a UI element exists in the front window.
Do you know if there's a way to detect whether a UI element exists in the front window?
Window Analysis Tool returns this for a plugin window:
window Output 1-2
button 1
button 2
checkbox "Button"
menu button "Editor"
static text "View:"
pop up button 1
static text "Side Chain:"
checkbox "Button"
checkbox "Compare"
group 1
button 1
button 2
group 2
button "Copy"
button "Paste"
group 3
button "Undo"
button "Redo"
pop up button 2
static text "Output 1-2"Hey Neil,
Clearly there are detectable elements. Run this in Script Debugger, and see what you get.
-Chris
tell application "System Events"
tell application process "Logic Pro"
properties of pop up button 1
end tell
end tell
In that post the condition was added to a macro Group.
