I’m trying to use AutoHotKey to allow me to quickly add a predefined label at the cursor. It’s working but slightly oddly. I’m wondering if anyone can suggest why it’s doing this. I am, by the way, using the Windows version of Audacity 2. I’m also not sure if this is best asked here or in the Audacity for Windows forum.
I want to click on the (zoomed in) waveform to place the cursor, then have the AutoHotKeyScript press control+B to create a label in the track under it, then type a “?” (for example) in the label and press Enter to close the label editing.
My AutoHotKeyScript is
^+1::
Send ^b?{Enter}
return
(The first line defines the hotkey - control+shift+1, the second sends the keys, the third quits the script.)
I click on the waveform then press control+shift+1. It places the label in the correct place, but then the display scrolls to the start of the track. If I press the right arrow key, I find that the cursor was where I left it.
Why does the display scroll to the start of the track?
I can work around it by adding a Right key after the Enter
Correction: it’s not scrolling to the start of the track after the label is entered, it’s actually just scrolling left a couple of screens like I pressed Page Down a couple of times. But not exactly two screens, so adding two PgUps to the string doesn’t get it back exactly where it was.
My {Right} workaround makes it usable, but it has the side effect that it scrolls the cursor to the middle of the screen, which is a little disorienting at times.
I also tried sending alt+t then s to create the label, but the result is the same.
The problem also occurs if I only send keys to create the label via the Tracks menu, but not to enter the string or close the label. It doesn’t occur if I just send a right arrow key - the cursor just moves right, and the display doesn’t scroll. I.e it’s the activating of the label command that’s doing it. But why does it not happen when I press the same keys manually?
I had a word with a college that does some scripting stuff, but it turns out that he does not use AutoHotKeys but some other scripting tools.
Based on your first post he suggested that AutoHotKeys may be sending a spurious {HOME} along with the {ENTER}.
Your second post gives me an idea…
How far exactly is it scrolling? 1 second? 15 seconds?
But a Home key press would move the cursor too, and it’s only scrolling the display to the left. The only ways I know of that do that are Page Down, shift+mouse wheel or clicking on the horizontal scrollbar.
If I get it to do 21 shift+Mouse wheel downs after the label is done, it gets it back to what appears to be exactly the right position. I’ve tried this at two very different zoom levels. This is a way better workaround than moving the cursor right after the label creation, but probably depends on mouse sensitivity settings.
I haven’t tested it exhaustively, but it seems to depend on the zoom level - the further I zoom in, the less it moves. After it happens, pressing Page Up a couple of times has always got the cursor back on screen so far, but not in the exact position it was in before (in relation to the window). The cursor doesn’t ever move in relation to the track time it was on before.
I believe AutoHotKey is capable of sending mouse commands, but it would be a bit odd if such a well known program was sending spurious shift+mouse wheel commands. Also, my test where I created a script to just send a single Right Arrow key worked fine. I just tried another test where I sent a Right Arrow key, then a Left, then created the label, and the problem still occurred.
I tried inserting a 1 second sleep period before it sends the keys, and the track didn’t scroll till the end of the period.
So if AutoHotKey is doing it, it’s not doing it when it activates the script. And seeing as it also happens if I create the label via the Tracks menu, it’s not something wrong with its ability to send a control+b. I think it must be something odd about the label command that doesn’t like AutoHotKey.
Can anyone recommend another equivalent Window program, so I can check if it’s AutoHotKey doing it?
Oh, right - I misunderstood what you meant. In that case I don’t have a clue, it sounds very weird.
It doesn’t happen with AutoKey on Linux, but I guess that doesn’t help you.
Not really , but at least it shows it can work. I’ve posted the same question to the AutoHotKey forum. Hopefully they won’t say they don’t use Audacity.
More information. I tried the same script on another PC, and on this one it’s not exactly 21 shift+mouse wheel moves (more like 30). I’m wondering if it depends on the size of the window.
I suspect this is a timing issue, with the text for the label being entered too quickly after the control+b. And that it’s not helped by my choice of “?” for test text.
If I change the test text to “xyx”, the display gets scrolled only slightly to put the new label in the middle of the window. If I add a 100ms Sleep before and after the control+b, it starts behaving itself properly, leaving the display unscrolled even if the text is question marks. But I don’t quite trust it, so I’m still sending a Right and Left after closing the label, just in case it decides to scroll off the screen. That should at least bring it to the middle of the screen.
If I don’t put the 100ms Sleep between the Right and the Left commands, sometimes the Left command doesn’t execute.
Conclusion (so far): timing matters, and AutoHotKey can be to quick for Audacity. I’ve no idea why question marks could especially upset it, but they do.
This is my (hopefully) final script
^+1:: ;Hotkey control+shift+1 to enter a preset label in the label track under the audio track, at the cursor position.
Sleep 100 ;Wait 100ms
Send ^b ; Create label at cursor
Sleep 100
Send ?? ;Enter text into label
Sleep 100
Send {Enter} ;Close the label
Sleep 100
Send {Right} ;Move right in case display has scrolled
Sleep 100
Send {Left} ;Move left back to the original cursor position
return
Bloody hell, it’s gone silly on me again. I fixed it by changing the first two Sleeps from 100ms to 500ms. That’s a long time for a computer, it must be very sensitive to delays.
Perhaps that’s to do with the length of this test track (about an hour of noise). I tried adding another couple of hours, and changed the display to Spectrogram with a window size of 32768 to make it go slow, and sure enough, it started misbehaving again.
I guess to make this bomb proof without adding huge delays, I need to get AutoHotKey to wait until the labelbox is ready for input. But how? AutoHotKey can check the colour of the pixels in a particular location, but I don’t know how reliable that would be. Perhaps this problem is a good justification for requesting an inbuilt macro facility.
I wonder why the first Sleep is necessary, before the control+b is sent. Just tried again without it, and it definitely needs it.
I can confirm that when zoomed in a long way, the same behaviour is repeatable with AutoKeys, but note that Audacity is designed to be used by humans
How fast can you type:
Ctrl+B test ENTER
I’m not a typist - it takes me about 1000 ms if I try to do it really quickly.
With AutoKeys it works 100% reliably on my machine with:
keyboard.send_keys("<ctrl>+b")
import time
time.sleep(0.1)
keyboard.send_keys("test<enter>")
time.sleep(0.1)
keyboard.send_keys("<left>")
time.sleep(0.1)
keyboard.send_keys("<right>")
So that is 0.1 seconds delay between commands and the label is complete in (more or less) 0.3 seconds.
I am the “college” to which Steve refers above. I use two other scripting facilities on Windows and find I also must insert “Wait X” statements ranging from X equal to .01 to .2 seconds. I have spent a lot of time working on the C++ code for Audacity and I think I understand what is happening. Audacity spends a lot of time “spinning” in a specific drawing loop after every event the app receives (there are other “spin” loops as well in the language translation code for instance). The amount of time spent spinning varies based on a number of factors. I brought this to the attention of the Developers but it is deep in the fundamental code and not of immediate interest to any Dev. Anyway, the best solution is to be generous with timing statements in your macros!
with no pausing and I’m zoomed in close, the screen scrolls horizontally as described by pshute.
I can’t produce the problem by speed typing with hands.
