Hi, I just updated from 2.2.2 to 2.3.0 and right away noticed the new “trackname display” with LONG name is obscuring the upper channel waveform peaks more than half way across the work-space. This is going to greatly interfere with editing… unless the new label background is transparent and fonts are smaller…
Also while typing this post, I hit a key on the Tab, Caps Locks, Shift side of the keyboard and 2.3.0 started Shrieking in the background… like a stuck recording. Exiting 2.3.0 stopped the shrieking. Very strange.
I’ve been discussing this with the developer involved (who also happens to be our Release Manager for the upcoming 2.3.1) release.
He says (as RM) that we have no time to do this for 2.3.1 - but we may be able to do something about it in the subsequent release.
For technical reasons down to drawing speed while Recording or Playing we may have to live with opaque trackname labels while recording and playing - but for when you are editing we think we can make them translucent.
BTW in default Waveform view if tour waveform is sufficiently big that the trackname obscures it than you are working with an unnecessarily hot signal - you only really need the waveform going up to 50% which corresponds roughly to -6dB on your meters.
I’ve read over all that you posted and understand the issues. Also noticed the `trackname´ changes to MIX after a mixing operation. Will leave track names on for now and observe how it goes. I think the trackname font is a bit too large. How about assigning a HOTKEY to toggle trackname ON/OFF ?
Many of my audio filenames are long, and the trackname becomes the filename after opening an audio.
I’ve written to the developer to sound out his thoughts on your suggestions.
Re. a keyboard shortcut for toggling the trackname on/off - I am strongly mined to agree with you. It’s a pain-in-the-butt to have to keep traipsing over into prefs to toggle it.
I guess that if we were to do this we would need to add a new command to the Tracks menu for the toggle - so that we could then assign a shortcut
(or, more likely, leave it blank for a custom shortcut).
What might prevent this is that we are very wary of creating command & Menu bloat - and we almost certainly would be unlikely to pre-assign a shortcut for it (we have far too many preassigned ones already).