I’ve looked around and have tried every solution on the web. Currently, I just want to make a macro that inputs values into the notch filter effect of the audacity program. Here are my attempts that don’t work.
on run
runme("5000")
end run
on runme(message)
tell application "Audacity"
#launch
activate
end tell
--this works
tell application "System Events"
tell process "Audacity"
tell menu bar 1
tell menu bar item "Effect"
tell menu "Effect"
click menu item "Notch Filter..."
end tell
end tell
end tell
end tell
end tell
delay 1
tell application "System Events"
tell process "Audacity"
#set visible to true
#set frontmost to true
tell window "Notch Filter"
#tell static text "Frequency (Hz):"
# set focused to true
#end tell
#return every attribute of static text "Frequency (Hz):"
#set value of attribute "AXFocused" of UI element "Frequency (Hz):" to true
--nothing with this text field works
tell UI element "Frequency (Hz):"
set focused to true
keystroke "a" using command down
keystroke message
delay 1
end tell
--this works
click button "OK"
end tell
end tell
end tell
end runme
You should click window “Notch Filter” to textfield get the focus:
Clicking the Notch Filter window does not focus the text field. This does not work. And I tried variations with it. The only time it seems to work is if I run it a second time while the Notch Filter window is still up, then it works.
on run
runme("5000")
end run
on runme(message)
tell application "Audacity" to activate
--this works
tell application "System Events"
tell process "Audacity"
tell menu bar 1
tell menu bar item "Effect"
tell menu "Effect"
click menu item "Notch Filter..."
end tell
end tell
end tell
end tell
end tell
delay 2
tell application "System Events"
tell process "Audacity"
#set visible to true
#set frontmost to true
tell window "Notch Filter"
click
delay 0.1
--nothing with this text field works
tell UI element "Frequency (Hz):"
keystroke "a" using command down
keystroke message
end tell
delay 1
--this works
click button "OK"
end tell
end tell
end tell
end runme
This works completely but I don’t know why.
on run
runme("4000")
delay 1.5
runme("5000")
end run
on runme(message)
tell application "Audacity" to activate
--this works
tell application "System Events"
tell process "Audacity"
tell menu bar 1
tell menu bar item "Effect"
tell menu "Effect"
click menu item "Notch Filter..."
end tell
end tell
end tell
end tell
end tell
tell application "Script Editor" to activate
tell application "Audacity" to activate
tell application "System Events"
tell process "Audacity"
tell window "Notch Filter"
--now this text field works
tell UI element "Frequency (Hz):"
keystroke "a" using command down
keystroke message
end tell
--this works
click button "OK"
end tell
end tell
end tell
end runme
Yes it may work for you but for me it puts me through an infinite loop. For some reason, it never thinks Notch Filter window exists.
The use case of this scenario is simply a macro that will run the Notch Filter effect every time I call the function.
I don’t need to automate any other processes. I’m working on whatever files and recordings I’m working on and then I need to apply a set of effects to each of them. All I need is the Notch Filter text field to become active. If I have to code it all in from the beginning then it isn’t a solution to be considered.
As of now, activating a separate window and then reactivating Audacity does make the text field selectable so it is as much of a solution that I need right now. If you can explain how to make the Notch Filter text field work in of itself then I could use that solution but I don’t want to go any deeper in automation and deal with even more problems that may come up from that.
I suspect that my version of Audacity versus my version of Mac OS may be creating different situations.
If that’s the case then activating another window and reactivating Audacity is the correct thing for me to do.
But why is it that it works this way? Is the Mac not handling windows properly? It shouldn’t create a Notch Filter window and then not ever see that it exists. That’s buggy behavior.
Forget for click the window “Notch Filter”. I found that the problem was other. Your last code is fine. Remove click after tell window “Notch Filter”. No need.
runme("4000")
runme("5000")
on runme(message)
tell application "Audacity" to activate
tell application "System Events" to tell application process "Audacity"
keystroke "a" using command down
tell menu bar 1 to tell menu bar item "Effect"
tell menu "Effect" to click menu item "Notch Filter..."
end tell
repeat until exists window "Notch Filter"
delay 0.1
end repeat
end tell
-- HERE for some reason "Audacity" gives default focus to button "Manage" instead of textfield
tell me to activate
tell application "Audacity" to activate
-- NOW a focus has the textfield
tell application "System Events" to tell application process "Audacity"
tell window "Notch Filter"
tell UI element "Frequency (Hz):"
keystroke message
delay 1
end tell
click button "OK"
end tell
end tell
tell application "Audacity" to activate
end runme
Indeed, Audacity has a very strange behavior. The following trick works too:
runme("4000")
runme("5000")
on runme(message)
tell application "Audacity" to activate
tell application "System Events" to tell application process "Audacity"
keystroke "a" using command down
tell menu bar 1 to tell menu bar item "Effect"
tell menu "Effect" to click menu item "Notch Filter..."
end tell
repeat until exists window "Notch Filter"
delay 0.1
end repeat
tell window "Notch Filter"
click button 3 -- Send window to background (focus has button "Manage")
perform action "AXRaise" -- Bring window to front (now focus has textfield)
tell UI element "Frequency (Hz):"
keystroke message
delay 1
end tell
click button "OK"
end tell
end tell
tell application "Audacity" to activate
end runme
What is strange here is that even though it has the focus on another button, that shouldn’t be stopping the automation from communicating with the text field. It can’t tell if the window exists and it can’t access other elements of the window just because it’s focus is on a button of the window? That doesn’t make sense. I should be able to set the focus to anything I want and access any UI element of a window regardless of what has been focused.
Here I see nothing strange. From the Audacity object model, you can see that the text field has no actions attached to it, so System Events cannot simulate any action (click from System Events didn’t send real mouse clicked event, it only performs some action of UI element, if any is attached by desiner of program). The textfield is controlled only by the application itself, as it is designed. For me, another is strange - when the window rises to the foreground by pressing the menu item “Notch Filter …”, the focus is received by the “Manage” button, and in other cases, the focus is received by the textfield. It confuses things. But something else is even worse - after entering the frequency and pressing the Enter key, the focus does not automatically go to the next textfield (many unscriptable apps works that way and I use that behavior to edit next textfield), and access to the “Q” textfield will be even harder. For this you have to use a third-party utility (as ClickClick, MouseTools) - to send a real click event to the textfield Q.
That’s incredible. I’m dumbfounded that a scriptable language entirely devoted to automation doesn’t support doing real mouse click events…this is exactly why no one thinks a Mac is a real computer. It’s like they are mocking the entire point of it. Who is seriously going to support automation of their own software? That’s absurd to think that they can require people to fit in hookups to THEIR automated scripting language…It’s an automated scripting language…it should just work out of the box! It’s THEIR operating system…they have complete control over the programs built for it…why are they making programs SUPPORT THEIR automation protocol? That just tops it all.