Bugzilla – Bug 1335
Moving tracks or swapping stereo channels during playback does not work correctly.
Last modified: 2019-10-21 13:56:39 UTC
Regression on 2.0.6. Playback does not reflect moving tracks by Tracks > Sort Tracks either. Reproduced on Mac and Windows so presumably "all". Channels of a split stereo track can be switched correctly between mono, left and right while playing. Split Stereo to Mono during playback works correctly.
Is the real bug that these operations are permitted at all during play? Reordering of tracks by dragging the track control panel is disabled during play, should not the moving of tracks by menu be too?
(In reply to Paul L from comment #1) > Reordering of tracks by dragging the track control panel is disabled during > play, should not the moving of tracks by menu be too? Yes I noticed that drag-move is not allowed during play. I assumed that had a safety reason. The live Swap Stereo Channels during playback can be useful. Also Move Track Up/Down can now be very conveniently executed with shortcuts, making that more useful. I found no evidence that move track up / down during play using the dropdown menu was unsafe in 2.0.6. And given other dropdown menu channel reallocations do work during playback, should not all of them?
(In reply to Paul L from comment #1) >Is the real bug that these operations are permitted at all during play? I'm minded to *strongly* agree with Paul here. ----------------------------------------------- However, testing on W10 with RC001 1) I agree that at Step 4 the audio does not change - I would NOT expect it to change, to do so would be a bug 2) at step ^ I confirm that the left channel, although displaying the proper waveform, is audibly silenced.
Promoting to P2 (In reply to Paul L from comment #1) >Is the real bug that these operations are permitted at all during play? I'm still minded to *strongly* agree with Paul here a- and believe that such operations should not be allowed during Playback or recording
Updated title as per Paul's Comment #2 I agree with him that is inconsistent that moving a track during playback or recording by dragging the TCP is inhibited - but use of the TCP context menu commands is not. There are a couple of specific issues: 1) On W10 with 2.3.3 using "Swap Stereo Channels" a crash occurs (hence the promotion to P1). This does not occur with 2.3.2 on W10 - nor does it happen on Mac with 2.3.3 jc010 latest alpha. If we do not fix the generality of 1335 then this use-case would become a new P1 by itself. 2) On Mac when using Record - when you click on the trackname or LDPBT for the context menu - the recording appears to be frozen from looking at the waveform. In fact it appears that the the recording is still taking place (rec. meters are bouncing nicely) - the waveform subsequently gets drawn when you re-click on the trackname or LDPBT to dismiss the context menu - or use one of the (currently) available context menu commands e.g. Swap Stereo Channels. This does not happen on W10 I fundamentally believe that we should "fix" this bug by denying access to the TCP context menu during playback and recording. I see no real reason for allowing access to the TCP context menu while the user is engaged in Playing or recording. The only possible exception I can possibly see is "Swap Stereo Channels" where users may want to experiment with that during playback. But that must be a rare use-case - and if we are concerned about that we could add a "Swap Stereo Channels" to the Tracks menu (but I could not offer strong support for that).
I am not getting the crash with swap stereo channels in either a debug or release build of 2.3.3 on windows. I have a 30s recording with a chirp left and white noise right. Playback continues with channels correctly swapped if I swap during playback. Can you give more details so that I can get this problem too?
(In reply to James Crook from comment #6) And restesting today with audacity-2.3.3-alpha-353-cff0011ee40dba6aa2e749ab99ea4efa57736796 I find I can no longer repeat this (and yet it was repeatable every time yesterday when I was testing) - so this leaves me confused)
Thre release note used to say >and if you use that menu to Swap Stereo Channels during playback, >the left channel is silenced.''' This appears to be no longer the case testing on W10 with audacity-2.3.3-alpha-353-cff0011ee40dba6aa2e749ab99ea4efa57736796 Also it said >Playback responds to the other commands in that menu. That also is not true - may sub-menu items are grayed out and unavailable during playback Accordingly I have trimmed the release note.
I restored the original bug title
(In reply to Peter Sampson from comment #9) and I trimmed out the > or swapping stereo channels as that bit now appears to work
The first part of the steps say >1 Generate Tone. >2 Tracks > Add New > Mono Track then Generate Noise. >3 Play. >4 While playing, click in the name of the tone track > Move Track Down so the noise is the upper track. >Audio does not change. But this is expected behavior - so one would not expect the playing of two mono tracks to change - so this part works. I also tested the remaining steps >5 Stop. Click in the name of the upper noise track > Make Stereo Track. Play. >6 While playing, click in the track name and Swap Stereo Channels. >Left channel playback is audibly silenced (but waveform remains ok). Tested with latest 2.3.3 alphas this now works fine - accordingly I shall close this bug as FIXED It is possible that Paul's under-the-hood changes for 2.3.3 inadvertently fixed this old bug.
