Bugzilla – Bug 231
Cut Preview should play all selected/sync-locked tracks, respecting Mute/Solo during preview
Last modified: 2018-09-13 09:29:34 UTC
When this is fixed so that all selected/sync-locked tracks play with Cut Preview, possibly Solo as well as Mute should let you choose tracks to preview the cut. Currently (with one track selected) you can mute the cut preview by muting the selected track, but soloing the other track still lets you hear cut preview. Possibly this suits people used to mixing desks (?) but I think it should be considered.
(In reply to comment #1) I think Cut Preview should play the mix, respecting Solo and Mute.
(In reply to comment #1) > Currently (with one track selected) you can mute the cut preview by > muting the selected track, but soloing the other track still lets you hear cut > preview Testing this, it seems the "rule" is that for multiple tracks you can mute cut preview if no more than one track of the tracks (other than the first) is selected, and if you mute that selected track. But selecting and muting the first track always mutes cut preview even if other tracks are selected. (In reply to comment #2) Bill wrote: > I think Cut Preview should play the mix, respecting Solo and Mute. It's certainly arguable, given standard playback does not depend on selection, making the current behaviour unexpected. It is potentially useful/time saving to retain the mute/solo states and determine which tracks cut preview by selected state. The problem with that is that to make sense, changing mute and solo would a) either have no effect during cut preview or b) would override the selection rule. b) just confuses my brain. a) is reasonable but still unexpected. I'm going to vote with Bill here. If we want to force soloing some tracks while retaining the existing mute/solo states I think this is better done by making a PFL button do that, or by some other "special" solo button.
(In reply to comment #3) Whatever the correct behavior should be, note these things: When the first (or only) selected track is mute 1) silence always plays, regardless of other tracks, as mentioned above, but also 2) the Play button does not pop up when the playback finishes. Number 2 does not happen when the first track is not mute. Perhaps these should be included in the description.
Problem 2 of the previous comment has been fixed.
Created attachment 567 [details] Fix (partial?) for bug 231 This patch causes Cut Preview to ignore the selected state of wave tracks and to respect the mute and solo settings, as they are when the command is given. However changing the mute and solo buttons during the cut preview play still has no effect. Is this good enough to close the issue or do we really want the latter fixed too?
... and I think that goes for pan/gain sliders too.
(In reply to comment #6) Do "mTemporaryTracks" in the proposed patch handle anything other than Cut Preview? If not, is "mTemporaryTracks" more meaningful than the pre-patch name "mCutPreviewTracks"?
(In reply to comment #8) As I mentioned elsewhere, yes I want to repurpose mTemporaryTracks for at least one other thing -- the play of selected frequencies. That is a working project now. I have not yet shared.
I also mentioned here http://audacity.238276.n2.nabble.com/2-1-1-Cut-Preview-does-not-respect-the-Time-Track-tt7567490.html that cut preview does not apply the Time Track warp. Should that be included in this bug description?
(In reply to comment #10) Paul wrote: > I also mentioned here > http://audacity.238276.n2.nabble.com/2-1-1-Cut-Preview-does-not-respect-the-Time-Track-tt7567490.html > that cut preview does not apply the Time Track warp. Should that be included > in this bug description? Is it the same bug? Shouldn't a Time Track be respected by Cut Preview whether the time track is selected or not?
(In reply to comment #11) Gale wrote: > Shouldn't a Time Track be respected by Cut Preview whether > the time track is selected or not? That depends on what "Preview" is intended to be. Is it supposed to preview the "effect applied to the audio", or, "the effect applied to the audio as it will be played in its current track context?" Currently it does the former. If we decide that it should do the latter then we are redefining the Preview feature from how it has been in all previous versions of Audacity. As such it makes a fundamental change to a very long-standing feature and I can only wonder why there is reluctance to discus the matter as a formal proposal.
(In reply to comment #12) Why not start a Proposal then, Steve, as long as it offers "play the mix" as one of the possible solutions? I still express the opinion that Time Track is no more part of the mix than Envelope points are. It just happens time warp points are in a different track.
(In reply to comment #13) Gale wrote: > Why not start a Proposal then, Steve, as long as it offers "play the mix" as > one of the possible solutions? because other than a few specific details on bugzilla, I'm not certain what you and Paul are proposing.
The bug actually described in this report is clear. The wider issues (timewarping) need to be taken to a proposal page, where we look at how much flexibility we want to give the user about their 'preview' pipeline. I think it is also a bug that cut preview does not respect mute-soling during preview. I would expect the 'correct' fix to this bug to use the same code as used for normal preview-selected, and so be consistent with the behaviour preview-selected has. Preview as currently implemented previews the effect applied to selected tracks. I don't think we should change that, so I am closing Paul's patch which plays all tracks.
(In reply to James Crook from comment #15) > The wider issues (timewarping) need to be taken to a proposal page Not at all on that specific, IMO. It's a clear bug that time tracks are not respected by Cut Preview. With that bug, even if one agrees that only the track to be affected by the cut is audible, you can't preview what the cut to that track only will actually sound like. Even standard preview respects time tracks. > also a bug that cut preview does not respect mute-soling during preview. Agreed. I think that can be dealt with in this bug so I added it to the title. > Preview as currently implemented previews the effect applied to selected > tracks. I don't think we should change that, so I am closing Paul's patch > which plays all tracks. Clearly Paul's patch did not fix the stated bug, which should be fixed because there is some convenience/use case in only previewing the selected track without having to press "Solo". Equally clearly at least three Team members want the ability for Cut Preview to play the mix. Why not add an enh issue to provide a checkbox in Playback Prefs to do that (there is plenty of space there) instead of having more discussions? That said, real time effect preview plays the mix, so the argument that preview only plays the selected track will become obsolete. If we don't want to give options then the "correct" future proof solution appears to be play the mix.
Comment 16 is well argued. Could the bug title be "Cut Preview mix/mute differs to RT Preview"? Either playing just the selection (extended by sync-lock if relevant) everywhere, or playing the mix is fine as a solution. We will likely go for playing the mix. We would then reopen Paul's patch, it becomes useful again, but probably apply a different fix that uses the RT pipeline (and thereby fix mute/solo as we play too at the same time). We would open a new enhancement issue for choice about whether RT preview plays the mix or plays the selected audio. I *think* but am not sure that there are other future options in there, such as where in the pipeline the RT effect is applied, e.g. before or after amplification/timewarping, whether we pass absence of audio to effects as silence or pass audio clip by clip. I think we need some discussion of that (in wiki) before we take a step on the enhancement road, even if the first step is just a tick box.
(In reply to Gale Andrews from comment #16) > It's a clear bug that time tracks are not respected by Cut Preview. > With that bug,... Perhaps I am misunderstanding you, but "respecting time tracks" is not a straightforward matter when it comes to Cut-Preview. If you apply the time track before copying the audio data, then the play speed for the "after cut" part of the preview will be wrong. It is therefore necessary to copy the audio data first, create the preview "mix" and then apply the warp, but how much audio do you copy from after the cut? If Cut Preview preferences are set to "1 second after cut region", is that 1 second of un-warped time, or 1 second of "warped time" in it's original track position, or 1 second of time after the cut region has been removed? In the current GitHub code, Time Tracks are very deliberately excluded from Cut Preview. ControlToolBar::PlayCurrentRegion specifically nulls out time tracks from Cut Preview by design.
(In reply to Steve Daulton from comment #18) > If Cut Preview preferences are set to "1 second after cut region", is that 1 > second of un-warped time, or 1 second of "warped time" in it's original track > position, or 1 second of time after the cut region has been removed? Wouldn't it be one second of time after the cut region has been removed?
Testing some years and versions on on W10 with audacity-2.3.0-alpha-115-2758491a4a6af166f2f6b7a517f4472b20505a1c I confirm that this bug is still extant. And I am *firmly* of the belief (in line with others in this old thread) that Play cut preview should play the cut preview of the mix and *not* just the top track. Contrast this with the behavior of the Play button on the selection which plays the selected mix, respecting mute/solo buttoning. This is so wrong imho that I am going to give it more prominence by raising it to P2 (and for me it is borderline P1) - not least because there is no workaround available for this.
(In reply to Peter Sampson from comment #20) > not least because there is no workaround available for this. Workaround: Do the cut, then Quick Play. Ctrl+Z to undo. So long as it is documented that the "C" shortcut previews cutting in ONE track only (the first track if multiple tracks are selected), then personally I'd not put this above "P3 Enh".
Yes there is that somewhat clunky workaround - but the manual says: >Plays audio excluding the selection. The amount of audio that is played >before and after the section is set by the Cut Preview setting in >Playback Preferences. It clearly doesn't say "just plays the selection in the top track" and "will play nothing if the top track is muted". So for ma this stays at P2 and should be fixed.
It's alos P2 as we have a gross inconsistency All the other play items in the Extra>Transport menu honor the mix - it is only the Plau Cut Preview that fails to honor the mix. See: https://alphamanual.audacityteam.org/man/Extra_Menu:_Transport
FWIW I looked into fixing this for 2.3.0. Cut Preview copies the first found track, cuts from it and then plays it. Paul has ideas for a 'play schedule' that will instead allow cut preview without copying. Much better. Meanwhile I've done a 'quick fix' of copying more tracks, just to close this long standing bug. Note that this approach is still sub par, as mute/solo will not act dynamically, and WAY more copying is done than necessary. Still it is enough to DEVEL FIX the bug, per title and steps to reproduce. DEVEL - FIX MADE https://github.com/audacity/audacity/commit/1deff18c15aa014c6d592a69fd13e0da446e8d08
(In reply to James Crook from comment #24) Testing on W10 with audacity-2.3.0-alpha-121-1deff18c15aa014c6d592a69fd13e0da446e8d08 I confirm that Play Cut Preview now behaves as James suggests in Comment #24 a) the mix prior to Plat Cut Preview is honored b) once Play Cut Preview is in play - the mix cannot be altered, further changes with the Mute/Sol buttons are ignored. The Other Extra>Transport menu items do honor the mix dynamically. I will document this in the Manual.
Testing on macOS 10.13.6 with 2.3.0 alpha 10Sep18 I confirm that Play Cut Preview behaves the same on Mac as it does on Windows
