How does the Track Panel become "active"?

I’m currently running Audacity 2.0.3 in Windows 7, SP1.

I’m a transcriber who uses OpenOffice on the right side of the screen and Audacity on the left side of the screen when I perform transcriptions. I use Autohotkey to automate the process, and while doing so, I have a keybind (in my case, Caps Lock), which allows me to alternate between the two windows. So for example, if I’m transcribing and the audio outpaces me, I press Caps Lock, which activates the Audacity window (and consequently, the Track Panel), sends a left arrow press, and then reactivates OpenOffice so I can continue typing. I am NOT in any way using or modifying Audacity source code to implement this–the transcription assistant I use is programmed in Autohotkey, and I interface with Audacity on the user end.

So it occurred to me a while back that I could eliminate the need to activate Audacity, send a keypress, and reactivate OpenOffice if I simply changed my Caps Lock keybind to send a left arrow keypress to Audacity while OpenOffice was still active. So I tapped into the Windows API and generated WM_KEYDOWN messages with Audacity’s hwnd as the target. Unfortunately, though this code CAN successfully send keypresses to other hwnds while they’re not active, including OpenOffice, it fails to send the messages to Audacity’s track panel while the window is not active (though I have successfully used it to adjust volume sliders and other things). Then I noticed that when you actually manually activate Audacity and it becomes the main window, the Track Panel receives a yellow highlight. When the Audacity window is deactivated, this highlight goes away. This leads me to believe that while Audacity is not the active window, it is performing some procedure which is also deactivating the track panel’s ability to receive input.

So I figured it may be possible to activate the Track Panel specifically, even if the window itself isn’t active, but I don’t know what cue Audacity is listening for in determining when to activate the Track Panel. Is it possible to spoof the Track Panel into “thinking” Audacity is active, or otherwise just activating the Track Panel without Audacity being the active window?

A lot of commands in Audacity require getting the current project. If there is more than one Audacity project open, and you perform an edit, you obviously only want the edit to occur in the “current project” - that is, the project window that is active. Similarly, if you press play or rewind, then you would only want the current project to do that, so it does not surprise me that Audacity refuses to respond to your key commands when the Track Panel is not active. Sorry, I don’t know how you could change that behaviour, I suspect that it would require major surgery on the Audacity code because there are a lot of checks and barriers built into Audacity to prevent things from happening when the project window is not active.

On the other hand, actions such as the playback volume slider are global - move the slider in one project and it will move in all open projects, so there is no requirement that the project window has to be active.

I believe the best solution to this problem is to update Audacity to wxWidgets 2.9.x or later version. Then if Audacity was coded accordingly it could support Global Shortcuts on Mac and Linux as well as Windows:

If Audacity supported global shortcuts then you could set an Audacity global shortcut for long or short seek backwards. Providing that shortcut did not conflict with system or other application shortcuts it would then work in Audacity even if Audacity was not the active application.

Once widgets supported global shortcuts cross-platform, an Audacity developer might be motivated to add support for them.

Unfortunately, wx 2.9 is not yet “stable” so Audacity is unlikely to update from the current 2.8.x stable series until there is a 2.9.x or 3.x stable series.

Even when there is a new stable series, there will be a great deal of work merely to change Audacity to use the new widgets series.


It could get messy if you had a global shortcut for Play and multiple projects were open.

I don’t think that’s a reason not to do it if we want Audacity to be more “competitive” for transcription or dictation.

Enabling global shortcuts would have to also enable whatever restrictions were necessary to avoid problems, possibly including preventing new project windows being opened by executing Audacity a second time (like it is on Linux now).

What other answer do you see? A special foot pedal that only drove Audacity may have exactly the same problems and would restrict the feature to those with money to spend.


Probably need to prevent more than one project (currently on Linux multiple projects can be opened from “File > New”, “File > Open”, “File > Recent”), so enabling global shortcuts would put Audacity into “single project mode”.

and Steve replied…

Unfortunately, there are very few people out there who are capable of, and willing to, make these kinds of modifications to the Audacity source code. To the best of my knowledge I am the only one on this forum who might be both willing and able to do this; I do not think you will be able to get anyone on the Audacity Development Team to make these changes and I am almost positive that if the changes were made the Audacity Development Team would not incorporate them into the shipped version of Audacity.

Then, there is the ugly question of compensation! Typically, if I can get what someone wants working in less than eight hours (I charge $200 per hour and have as much work as a want) I do it for free; thereafter, I work with the requester to create a fully specified design for the project and produce a bid for the work with scheduled payments based on waypoints in the project. The first payment is always a donation directly to the Audacity team as a thank you to them for all the hard work they put in; the size of this donation is based on the overall size of the project and run somewhere around 10% of the overall bid; I do not do any serious coding work until this donation has been received. Unless specifically stated in a contract otherwise, any programming work that I do remains my property to do with as I choose. All that being said…

You and I could develop a customized version of Audacity which did exactly what you want but would be restricted (with a Preference item to turn this feature on and off) to having a single Project window open; we should also add a special command with a user-configurable keyboard shortcut which AutoHotkey would use to perform the same action you now get with the keypress (because we want it defeated with the above-mentioned preference item so that we do not confuse Audacity and AutoHotkey). Having this Preference item would avoid the problem of having two different versions of Audacity - one for use in your workflow as a transcriber and another for generalized audio editing (where you would be likely to want multiple Projects).

I do not use AutoHotkey (I make some use of AutoIt3) so you would need to do all of the real beta testing. I suspect that if you did not want a lot of fancy design work and simply wanted to (conditionally) restrict Audacity to a single Project, add the the Preference item, and add the custom command for which AutoHotkey would be the driver I could do this for free as it is PROBABLY fairly easy.

The “fancy design work” that I envision would be things like turning off all menu items that would be capable of starting a new Project (my current thoughts would be that if you issued any command which would start a new Project a Dialog would open explaining that this was a custom version which only supported one Project); additional fancy stuff would involve language translation for the new strings which would be needed (new Preference entry, new warning dialog etc.). These two items alone could add an indeterminant amount of time and easily $1000 or more.

Sorry for being so long-winded here! If this sounds like something you would like to explore let me know. I have a few hours of spare time in the next couple days but thereafter probably could not devote any serious time to this until next week. If you would like to check my references ask Gale and Steve (the other two respondents to this thread); while I have provided code for Audacity and am currently one of the Editors of the Manual I am not on the official Audacity Development Team.

Thanks for the replies all.

To steve: Before posting I dug around a bit in the Audacity source, and I had suspected as much. It might behoove me to just increase my familiarity with the Audacity source code, dabble around a bit, and maybe through progressive familiarity, performing the necessary surgery won’t seem so “major.” Unrelated: This is only the second time I’ve posted in this forum, the first time being four years ago, and you were the first person to reply then, too.

To Gale: The widgets update sounds promising. In almost all cases, when I’m transcribing, I only have one project open, so global shortcuts potentially conflicting with other projects is not really an issue for me. I might even try wx 2.9 before it’s stable and report back if it seems to be working for me.

To Edgar: Unfortunately, I’m but one man doing freelance transcription, so as much as I’d like to engage in a full scale revamp of Audacity to suit my needs, I don’t have the resources or the time. I do appreciate your offer to look into the source code on a minor level–I’ve looked over it myself, and I’d require quite a lot of messing around before I felt comfortable, but it might be worth it (and bring unexpected benefits in the long run, too!). Your eagerness to help is most appreciated, and if I have any non-imposing questions or develop more interest in pursuing deeper Audacity modifications, I will let you know. Thank you very much!

To anyone: I’ve messed around with a bit of SDL, but it’s incredibly inconsistent and buggy with respect to audio playback. Since my initial post, I tried messing around with SFML, which just released 2.1 the other day, and while it was better than SDL, it’s still somewhat buggy (it likes to stop working if you issue it too many commands) and only supports .ogg natively. And of course, none of these options brings the robust suite of audio processing tools to the table or the handy audio visualization, which is more helpful than you might think for transcription, so I’d like to stick with Audacity if I can make it work. Gale’s right that Audacity leaves a little bit to be desired for transcriptionists, but it’s actually close enough that I’ve never seen the need to search for an enterprise product (though I do more supportive third party scripting than I suspect most transcriptionists do).

Don’t hesitate to ask; I frequently have blocks of spare time and tweaking the Audacity source code is one of my favorite hobbies!