Re: [Audacity-quality] Note Track (MIDI) Sync-lock bug
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
|
From: James C. <cr...@in...> - 2017-06-29 16:22:10
|
On the zebra striping, making the clocks darker helps. So does making the clocks larger (on all tracks). Makes the image less busy/fussy. For 2.2.0 I think going with current size/look is OK. We then build up a list of appearance changes we would like, for example I would like the thumb images to be larger too, so that the highlit thumb can be bigger than unhighlit. My preferred long term solution is not to decorate the selection at all. Instead to have a tree of tracks, rather than a list, and the tree 'brackets' (the indicators that several tracks have the same root) hold the iconic information that they are a track selection group that are sync-locked together. IF that is done then it is enough that selections automatically appear for all tracks in the group. On 6/29/2017 4:54 PM, Peter Sampson wrote: > On Thu, Jun 29, 2017 at 4:35 PM, Steve the Fiddle <ste...@gm...> > wrote: > >> >> On 29 June 2017 at 16:06, James Crook <cr...@in...> wrote: >>> On 6/29/2017 3:34 PM, Gale Andrews wrote: >>> >>> Clocks still cant be seen behind the notes, of course. >>> >>> Consider the attached. The whiter region is "sync-lock >>> selected". So do the clocks go wherever there isn't a note? >>> >>> Yes. >>> >>> We would need to apply the clocks AFTER the zebra striping. >>> We also seem to need to apply zebra striping to the selection, which is a >>> separate (minor) bug/enhancement. >> Playing with some mock-ups. It's not easy to get everything really clear >> without being visually "very busy", but it is certainly possible to show >> clocks in most cases: >> > Yes it's busy - but I think it's better to be clear to users just what the > implied selection is. > > Peter. > > > >> >> >> Steve >> >> >> >> >>> If we do both, even on your example (and some more extreme ones that I >>> have), I think the clocks would be clear. I only see a potential problem >>> with very short selections, and that problem exists for normal waveform >> view >>> too. >>> >>> --James. >>> >>> >>> >>> >>> I think this will be harder to see and more disruptive in note >>> tracks (and in spectrograms) than in audio tracks. >>> >>> >>> Gale >>> >>> >>> On 29 June 2017 at 14:34, Peter Sampson <pet...@gm...> >>> wrote: >>> >>> On Thu, Jun 29, 2017 at 2:22 PM, Gale Andrews <ga...@au...> >> wrote: >>> The clocks would have to go over the top of the note tracks, wouldn't >>> they, in order to be visible? >>> >>> No (just as with audio tracks) the clocks would go over tha background >>> and behind the notes. >>> >>> >>> And I've just remembered that we encounter the same no-clocks when the >>> sync-locked audio tracks are in Spectogram view ... >>> >>> Peter. >>> >>> >>> Arguably that would look very weird and >>> obscure detail. I think P3 is about as high as bug 1671 should go >>> unless we are going to improve the wallpaper, but it's already a >>> problem whether we add MIDI playback or not. >>> >>> One solution could be to only show the clocks at the corners of the >>> sync-locked selection. >>> >>> >>> >>> Gale >>> >>> >>> On 29 June 2017 at 11:04, Peter Sampson <pet...@gm...> >>> wrote: >>> >>> Please note that if we are to release MIDI playback for 2.2.0, then >>> there is >>> a bug >>> that I logged yesterday on Bugzilla that probably deserves a higher >>> priority, probably >>> P2 at least. >>> >>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1671 >>> Clock icons do not propagate into Sync-locked Note Tracks >>> >>> This is a visual-cue that's missing but - it does not affect the >>> Sync-locking which works as >>> expected when Note tracks are inclided in a sync-lock group. >>> >>> And therein lies the problem, the lack of the visual cue may leave the >>> user >>> unaware that the >>> Note Track(s) will also be affected by Delete, Cut and Paste in other >>> members of the sync-locked >>> track group. >>> >>> >>> If we are not going to be having MIDI playback for 2.2.0 then it can >>> remain >>> at P4 for now. >>> >>> Peter. >>> >>> |