I just upgraded to 2.1.2 on Windows 10. About half of the time when I hit the spacebar to start playing a section of audio, nothing happens. If I hit the spacebar again, it will play. It seems like I need to wait about half a second between the last time I clicked a mouse button and when I press the spacebar, which is really screwing up my productivity. This didn’t happen in 2.1.1. I’ve looked through the Preferences to see if there is some kind of new setting for this, and didn’t see anything. Did something change, or is this a bug?
I’ve not noticed the problem here (but I’m not on Windows 10).
Are you sure it’s not just your spacebar sticking a bit?
Does the problem happen if you click the Play button?
Are you able to change the shortcut to a different key to see if the problem still occurs?
I’m sure it isn’t the physical keyboard because I use it all day long for audio recording, editing, and writing, and it doesn’t happen in any other program. More importantly, this problem doesn’t occur in Audacity 2.1.1 on the same machine. I just tested it out prior to this post to ensure that I wasn’t doing anything differently process-wise. Every few select-and-play operations I do between the mouse and the keyboard results in not playing, whereupon I have to hit the spacebar a second time to make it play.
I’ve tried clicking the play button in the toolbar, and can’t reproduce the problem. It’s only when I’ve used the mouse to select part of a waveform and hit the spacebar to play it. I do this very often when looking for a little click, voice crack, or other imperfection that I can hear but can’t easily see. I do this very quickly, so it seems like 2.1.2 introduced some kind of “wait this long after the mouse is idle before accepting input from the keyboard” feature. If I slow down my pace, it doesn’t happen.
I went into the mapping preferences to map a different key, but then realized that it would screw up my mappings, and at the moment I’ve just got to get some work done, so I’m just going to switch back to 2.1.1 for now.
Alright, try testing with this:
Right-click and hold, then drag to the right to select some audio. Do not release the mouse button after dragging (as though you might still adjust the selection). Press the spacebar.
In 2.1.1: it plays the selection
In 2.1.2: it does not play
[corrected typo?? Koz]
I can reproduce that on Windows 10 (not tested anywhere else yet).
Providing I do release the mouse I don’t have to wait for playback after pressing SPACE.
Would you find it easier to drag and release in the Timeline above the waves? It won’t play until you do release, but you won’t have to press SPACE.
Gale
Hmm… I could probably do that, but I’m just going to stick with 2.1.1, since 2.1.2 requires these changes to my workflow habits and doesn’t have any of the improvements that I was hoping for (Equalizer and Change Pitch settings in chains). I wish I had the time/money/ability to help instead of just complain.
I just uninstalled an older version and installed 2.1.2 and I have the same problem. The spacebar now requires two taps to start playing after I use the mouse to place the edit point. It used to require one. To make matters worse, it doesn’t do it in every case, so sometimes if I tap twice, it starts then stops.
This is maddening and is killing my productivity. I produce and edit audio books where each file has dozens of simple cuts where a narrator makes a mistake, backs up a few words, then starts over. All I do is cut out the mistake and keep moving, and speed is the key. Is there a fix for this? If not, how do I find a legacy version of 2.1.1 that I can trust?

I just uninstalled an older version and installed 2.1.2 and I have the same problem. The spacebar now requires two taps to start playing after I use the mouse to place the edit point. It used to require one. To make matters worse, it doesn’t do it in every case, so sometimes if I tap twice, it starts then stops.
This is maddening and is killing my productivity. I produce and edit audio books where each file has dozens of simple cuts where a narrator makes a mistake, backs up a few words, then starts over. All I do is cut out the mistake and keep moving, and speed is the key. Is there a fix for this? If not, how do I find a legacy version of 2.1.1 that I can trust?
The answer is the same too. SPACE does not work while mouse is down. Give Timeline Quick-Play a try, but if you can’t get used to it, you can find 2.1.1 here (it’s my server): http://gaclrecords.org.uk/legacy/. It is always good to test the file at https://www.virustotal.com/, wherever you download from. See Online safety when downloading.
Gale
I’ve had to adjust my workflow to accommodate the bug. Basically I’ve retrained my hands to not use the keyboard while the mouse button is clicked. I still miss a command every now and then, though, and I hope this issue is addressed in the next release. More than that, though, I really, really, really need my Chains list to be in alphabetical order…

I’ve had to adjust my workflow to accommodate the bug.
It is not a bug. It was a feature change imposed by the new version of wxWidgets that we upgraded to. We are tracking the issue, so that we know that users are affected.
I think Timeline Quick-Play is usable as an alternative, but more risky that you could unintentionally create a different selection than the one you are working with.

I really, really, really need my Chains list to be in alphabetical order…
You can use Windows or Mac, if you have one. In fact if you use Mac, you can (for now) use your old workflow of SPACE while mouse is down.
Gale
I’ll go back to reel-to-reel before I use a Mac. Windows crashes when I run a chain on selections longer than 30 minutes. Besides, my workstation is set up and working nicely with Linux.
It seems to me that a feature should be able to be turned on and off. If I had the time, maybe I’d try to roll back the undesirable wxwidgets changes and fork it.

If I had the time, maybe I’d try to roll back the undesirable wxwidgets changes and fork it.
Linux was the main reason that we updated to Wx3. Most distributions have phased out Wx2.8 and were building Audacity with Wx3, which was creating LOTS of serious bug because Audacity was written for Wx2.8. We really had no choice but to update (or stop supporting Linux, which we decided was not an option).

Windows crashes when I run a chain on selections longer than 30 minutes.
That is probably because your Chain includes a Nyquist effect that writes its audio data to memory. If it does not happen the same on Linux, that is because Linux lets you use more than 2 GB of RAM for the Audacity process. It will still crash when it gets close to 4 GB RAM, because Nyquist is 32-bit.
If you have now migrated from Windows to Linux, you should be able to build the Audacity 2.1.1 source tarball against wxWidgets 2.8.12.
Gale