Paul Licameli
2017-05-02 04:58:37 UTC
I reviewed Pokechu22's work and I have merged the parts considered ready,
after rebasing the commits and permuting their sequence a bit. Also the
new call to MakeParentModifyState which I don't doubt is correct. Just two
commits still left out.
For convenience I have also enabled EXPERIMENTAL_MID_OUT on all platforms.
This is not final, but may be reverted before release.
Attention, Pokechu22, QA and Manual:
Note tracks are already a feature of released Audacity. Described below
are new enhancements to editing and visualizing them. These changes are
independent of playback, and so WILL BE IN 2.2.0, even if the rest of the
project is unready. There are bugs yet, but I expect them to be easily
fixed in the time frame.
- A selection in a Note track should now be silenceable (as with Ctrl +
L and Ctrl + T) and sync-lock adjustments of Note tracks should be
implemented (as when deleting or inserting in a wave track above it) .
These features need testing.
- Ctrl + Shift + F affects both MIDI and Wave track heights.
- The old code is now enabled, to draw sixteen toggle buttons that you
can click to hide (and, when playback is enabled, to mute) correspondingly
colored notes on the piano roll display. Left to toggle one channel, right
to solo or un-solo that channel.
- Undo/Redo restores the state of MIDI channel muting, analogously with
wave track muting state.
- The display of the top and bottom edges of the buttons is not right
yet, perhaps because James independently changed the height of the Mute and
Solo buttons and the sliders. So don't make screen shots yet.
- Probably, some constants in TrackPanel.cpp simply need changing and
that's all. But I would rather see this fixed with enum names that are
reused, than still see "magic numbers" (like 19 or 34 or 38 or 48) that
occur in multiple places and look only "coincidentally" the same.
- If I drag the bottom edge of the note track up, then controls should
disappear as the height becomes too small. But I don't see this happening
cleanly. The borders of Mute and Solo remain even after those buttons
disappear. This does not happen with Wave tracks. Also when the colored
buttons disappear, a short vertical stroke appears over part of the menu
button.
- Pokechu: I may misunderstand?
- should #define CHANNEL_BIT(c) (1 << (c & ALL_CHANNELS))
- instead read #define CHANNEL_BIT(c) ((1 << c) & ALL_CHANNELS)
The MIDI playback project will invite users to make more use of MIDI
tracks, and therefore to try editing them. Such existing but little used
editing features as we already have, need reexamining and improvement.
- Time-shifting (Repeat, Reverse, Change Speed, Change Tempo) and
pitch-shifting effects (Change Speed again, and Change Pitch) need some
renewed testing. (These lists may not be exhaustive.)
- A change in the status bar message, for mouse-over of the colored
buttons, is still lacking. (See TrackPanel::SetCursorAndTipWhenInLabel)
- It seems that editing operations like copy, cut, paste, delete, etc.
affect MIDI notes according to whether the onset of the notes is in the
selected time range. The sustain or release of the notes doesn't matter.
- This is unlike the behavior of wave tracks. This is not to say
it's wrong, MIDI being a different thing after all.
- Whether we agree that it is right or wrong, the editing behavior we
see should be consistently the right behavior.
- There is a "stretching" feature of note tracks. You can even do it in
2.1.3. But I think its behavior is weird and buggy. How do we fix it for
2.2.0? If nobody finds the time to fix this feature, then I am inclined to
disable it.
- Select a region of a note track. Put the cursor in the selection
and near the middle of the track height. Cursor changes to a box with a
cross-hair.
- Click and drag left and right, and see changes in the timing of the
notes, but not the pitch.
- Notes both within the selection, and right of it, but not left of
it, can be changed.
- I don't understand the intended behavior. Actual behavior is very
weird. It is not the case that the results you see are simply a function
of mouse x coordinate. Rather, results are path dependent.
- Incremental changes are not consolidated in Undo history, as we
would do for changes like time-shift of clips.
- In my opinion, all editing operations should affect channels
independently of whether they are mute, just as it is done with wave
tracks. The analogy makes sense. If you argue for the opposite, still
again, whatever we implement should be consistent across all operations.
- Consider the following speculative implications to be much lower
priority than the rest of the playback project; defer to future
versions if
time does not permit. Let's think about them some but not get diverted.
- Would it make better sense to change display of muted channels in
the piano roll, so they are not completely invisible?
- Would we also want some means to edit channels separately too? At
the least, perhaps, a drop-down menu item that moves the unmuted channels
to a new note track?
- Splitting of a note track into channels suggests merging is needed
too.
- Or is my opinion wrong: should the state of colored buttons be a
"selection" state, finer than track selection, and affecting more than
playback, but rather affecting all editing?
PRL
after rebasing the commits and permuting their sequence a bit. Also the
new call to MakeParentModifyState which I don't doubt is correct. Just two
commits still left out.
For convenience I have also enabled EXPERIMENTAL_MID_OUT on all platforms.
This is not final, but may be reverted before release.
Attention, Pokechu22, QA and Manual:
Note tracks are already a feature of released Audacity. Described below
are new enhancements to editing and visualizing them. These changes are
independent of playback, and so WILL BE IN 2.2.0, even if the rest of the
project is unready. There are bugs yet, but I expect them to be easily
fixed in the time frame.
- A selection in a Note track should now be silenceable (as with Ctrl +
L and Ctrl + T) and sync-lock adjustments of Note tracks should be
implemented (as when deleting or inserting in a wave track above it) .
These features need testing.
- Ctrl + Shift + F affects both MIDI and Wave track heights.
- The old code is now enabled, to draw sixteen toggle buttons that you
can click to hide (and, when playback is enabled, to mute) correspondingly
colored notes on the piano roll display. Left to toggle one channel, right
to solo or un-solo that channel.
- Undo/Redo restores the state of MIDI channel muting, analogously with
wave track muting state.
- The display of the top and bottom edges of the buttons is not right
yet, perhaps because James independently changed the height of the Mute and
Solo buttons and the sliders. So don't make screen shots yet.
- Probably, some constants in TrackPanel.cpp simply need changing and
that's all. But I would rather see this fixed with enum names that are
reused, than still see "magic numbers" (like 19 or 34 or 38 or 48) that
occur in multiple places and look only "coincidentally" the same.
- If I drag the bottom edge of the note track up, then controls should
disappear as the height becomes too small. But I don't see this happening
cleanly. The borders of Mute and Solo remain even after those buttons
disappear. This does not happen with Wave tracks. Also when the colored
buttons disappear, a short vertical stroke appears over part of the menu
button.
- Pokechu: I may misunderstand?
- should #define CHANNEL_BIT(c) (1 << (c & ALL_CHANNELS))
- instead read #define CHANNEL_BIT(c) ((1 << c) & ALL_CHANNELS)
The MIDI playback project will invite users to make more use of MIDI
tracks, and therefore to try editing them. Such existing but little used
editing features as we already have, need reexamining and improvement.
- Time-shifting (Repeat, Reverse, Change Speed, Change Tempo) and
pitch-shifting effects (Change Speed again, and Change Pitch) need some
renewed testing. (These lists may not be exhaustive.)
- A change in the status bar message, for mouse-over of the colored
buttons, is still lacking. (See TrackPanel::SetCursorAndTipWhenInLabel)
- It seems that editing operations like copy, cut, paste, delete, etc.
affect MIDI notes according to whether the onset of the notes is in the
selected time range. The sustain or release of the notes doesn't matter.
- This is unlike the behavior of wave tracks. This is not to say
it's wrong, MIDI being a different thing after all.
- Whether we agree that it is right or wrong, the editing behavior we
see should be consistently the right behavior.
- There is a "stretching" feature of note tracks. You can even do it in
2.1.3. But I think its behavior is weird and buggy. How do we fix it for
2.2.0? If nobody finds the time to fix this feature, then I am inclined to
disable it.
- Select a region of a note track. Put the cursor in the selection
and near the middle of the track height. Cursor changes to a box with a
cross-hair.
- Click and drag left and right, and see changes in the timing of the
notes, but not the pitch.
- Notes both within the selection, and right of it, but not left of
it, can be changed.
- I don't understand the intended behavior. Actual behavior is very
weird. It is not the case that the results you see are simply a function
of mouse x coordinate. Rather, results are path dependent.
- Incremental changes are not consolidated in Undo history, as we
would do for changes like time-shift of clips.
- In my opinion, all editing operations should affect channels
independently of whether they are mute, just as it is done with wave
tracks. The analogy makes sense. If you argue for the opposite, still
again, whatever we implement should be consistent across all operations.
- Consider the following speculative implications to be much lower
priority than the rest of the playback project; defer to future
versions if
time does not permit. Let's think about them some but not get diverted.
- Would it make better sense to change display of muted channels in
the piano roll, so they are not completely invisible?
- Would we also want some means to edit channels separately too? At
the least, perhaps, a drop-down menu item that moves the unmuted channels
to a new note track?
- Splitting of a note track into channels suggests merging is needed
too.
- Or is my opinion wrong: should the state of colored buttons be a
"selection" state, finer than track selection, and affecting more than
playback, but rather affecting all editing?
PRL