Thank you so much Steve and Gale. The discoverability fix that Gale proposed is way better because you can start playing in the exact same position you were, so you don’t have to click a little on the side of the triangle and worry about where exactly the cursor was and find the closest spot that does not activate the double arrow pointer. You just click on any area above the triangle and it starts playing.
Nice!
When is Audacity 2.1.0 going to be released?
And the version that fixes this?
Hopefully in a few weeks.
2.1.0 won’t have the fix because it is too close to the release.
If and when the fix is committed to the code base, you would be able to try it out by downloading the latest alpha build (if we continue to provide them) or by compiling Audacity yourself from source code.
Gale
Oh, you were right, Audacity 2.1.0 hasn’t fixed this “bug”. And still no real-time effects (so we don’t have to wait the tracks to be processed to play them 1 tone lower or at x0.20 speed), like change/shift pitch or tempo. 
As explained in Missing features - Audacity Support, real-time preview is currently only for LADSPA, VST and Audio Unit (OS X) effects. I expect we’ll be working on implementing real-time preview for built-in effects for the 2.1.1 release but we’re not guaranteeing that will be done for 2.1.1.
Note that if you don’t mind pitch being affected, you can play tracks at different speeds without processing them by using Time Tracks or Transcription Toolbar.
Gale
Yeah, since I use Audacity basically to play along with my guitar, pitch is obviously important. Right now I have to import a track or tracks, select all of them, change the pitch 1/2 tone down, then change the speed, etc. If I could do this without waiting the data to be processed, it would be a little more comfortable. I don’t want a preview feature, if that’s what you were referring to. I’d love to play an imported file with the pitch and speed that I choose, that’s what I’m looking for. Anyways, right now what really annoys me is the main bug of this thread, the upper bar issue.
I use Audacity to sync audios from films too. But when you work with 2h length tracks, Audacity gets impossible to use with a Hard Disc Drive, so much lag and waiting. You must buy an SSD and work on it with Audacity. As soon as I can, I’m gonna throw away this slow Hard Disk Drive and I’m gonna replace it with a 1TB SSD, so I can work fast, with a fluid and nice experience.
Thanks for replying, I’ll be waiting for the real-time effects and the fix in the upper bar.
Yes - 1.2.6 used to be faster on long projects than 2.0.x versions are.
There is an aim to work on this in the near future - an SSD should not be needed. As things are at the moment, there will still be some potential delay with an SSD. 
Gale
An SSD should not be needed?
Man, each time I import an audio from a film, it takes like 6 minutes to be imported, and it’s HDD’s fault. An SSD here would totally destroy a HDD.
So yeah, I think an SSD is kind of “must-have” when working with Audacity, specially if you work with audio tracks that are longer than 15 minutos aprox.
I don’t know why you say an SSD is no needed. In fact, Audacity is mostly the very reason I want a SSD of 1TB.
I mean, Audacity should not be so slow that an SSD is needed for a decent experience with long tracks.
Gale
Oh, got ya. But isn’t this slowness related to hardware limits?
If it were Audacity’s fault, the HDD shouldn’t have anything to do with it, so it would be like at 20% of load, for example. In any event, if it were Audacity’s lack of optimization, the CPU, which is the one that runs Audacity, would be the limit here, right? But it’s not. I’m confused, lol 
This is getting way off topic, but the essence of the “slow” problem is believed to be that Audacity does too much examination of the entire data for its autorecovery system when it doesn’t need to.
It will always make a difference how fast the drive I/O is, but if the data examination/writing of the “autosave” recovery file was quicker then even a slow drive would benefit.
You could always experiment with using a RAM drive and see how much faster that was, but if there is a crash your data is gone.
Some day we will make On-Demand Loading available for files imported by FFmpeg, like we do for WAV/AIFF imported without FFmpeg. That would make the actual importing of audio from video files much faster.
Gale
And it limits the size available for temporary data, which can be huge for large projects.
Mark this problem as solved, cause in version 2.1.1 is SOLVED!!! 
Thank you developers!
I marked it [SOLVED].
Many thanks to Steve who worked on this.
Gale