Keyboard combinations

I was trying to type in the title of a song with a “¡” in it, and I found that typing anything in with keyboard combinations that make use of the “alt” button (e.g. “á”, alt + e, a) can be difficult. It usually won’t let you type anything at all, but sometimes, it just works for some reason.

What is the exact three-section version number of Audacity? (look in: “Audacity menu > About Audacity”)


This was in a label, by the way, not for metadata.

First thing: it is not recommended to use special characters for file names. Doing so can make the files fail in some applications / devices.

Second point: Audacity has a lot of pre-defined keyboard shortcuts (see: Attempting to use Alt+character is very likely to collide with one of these key bindings.

In Audacity 2.1.2, special characters (such as “á”) should work in labels, but it may be necessary to copy and paste the text rather than trying to type it directly into the label.

I don’t have a lot of files with special characters in their names, but the few that I do have seem to work fine on Macs and iPhones and iPods. You can easily type special characters directly into text boxes for metadata, so can Audacity be made to recognize text boxes for labels in the same way? By the way, I figured out why it sometimes works: if you hit alt + u (¨), you can type in a special character immediately afterwards.

Can it?

It looks like no-one knew the answer, in which case please allow some time for it to be tested.

In 2.1.2 and 2.1.3-alpha, diacritic characters (produced with Option key combinations or by long pressing a character then choosing from a context menu) both work in Metadata Editor and file open/save dialogues. Neither work in labels in 2.1.2/2.1.3 alpha. Labels are not a standard text box.

The option key combinations worked with a bug in 2.1.1, that the first press of the option key combination did not produce the diacritic, but if you repeated the combination then two instances of the diacritic appeared. You could then type the character to which the diacritic was to be applied, which would appear as the second character. The first diacritic remained behind as it was.

I’ll add this feature lack/partial regression to our bug tracker presently, but without a “proper” text box it may not be an easy fix.

If you want 2.1.1 you can obtain “2.1.1 screen-reader” from


If it’s any help, it works just fine in 2.1.0.

2.1.0 has the same problem on Sierra for me as 2.1.1. I agree it works in those Audacity versions if you accept that the option combination shows you no feedback of the diacritic chosen, and you then type the required character. However you can see from using option combinations in Audacity’s Metadata Editor and Open/Save dialogues that you should be shown the chosen diacritic.


I’m also doing it on Sierra, and the only problem I have is that it doesn’t appear until you type in the character the diacritic is to be applied to, not that you have to type it in twice. That should be good enough if you find you have serious problems in getting it to work exactly right; it really isn’t a big deal if it doesn’t appear beforehand if you do.

Although now I see what you mean, but as I said, it really isn’t a big deal if it doesn’t appear beforehand.

This hasn’t been fixed, and it doesn’t appear in the release notes, are you still working on it?

Thanks for following up on this. As far as I can tell this was never logged as a bug. I’ll do that now.
– Bill