PianoRoll: Draw note names on all white keys, highlight white keys #2285
Conversation
|
Related to issue #2280. |
|
Very nice! |
|
👍 Very clear and readable. |
|
Prior to this, the C-notes were easier to locate. Can we consider keeping the C-notes quick to locate (bold perhaps)?
To be more musically accurate, The only other criticism I have is that the Hope you don't mind the constructive criticism. 👍 |
|
I think drawing the C notes bold could look a bit odd because they might stick out too much. What do you think about drawing all other notes in a lighter color? I have no problem with implementing it in the I can change the Last but not least, thanks for the criticism! Constructive criticism is always welcome. 😃 |
|
Top notch. Agree with all points. |
|
P.S. It is quite amazing what a difference the line can make in that scale. Good choice there! |
| case 11: | ||
| yCorrectionForNoteLabels = 2; | ||
| break; | ||
| } |
There was a problem hiding this comment.
why not use this switch block instead of the one in the new function isWhiteKey() (aka isBlackKey()) and then also replace the if statement underneath with if ( yCorrectionForNoteLabels != 0 )?
There was a problem hiding this comment.
@AndiEcker Thanks for the review! I was thinking about that as well but then decided to not merge these functions because they are concerned with different things. The function isWhiteKey is concerned with determining whether a key number corresponds to a note in the C major scale. Therefore it's rather generic and might also be used in other context in the class as well. The commented code block on the other hand is very specific as it is used in the context of rendering the note labels on the keys.
Using something like yCorrectionForNoteLabels != 0 would be to implicit for my taste and might also break as soon as someone decides to also render the note labels for the black keys which then might have a non zero correction value as well.
There was a problem hiding this comment.
Thanks for you explanations!!! I now fully agree with you - your approach is resulting in cleaner code (although more code lines;).
There was a problem hiding this comment.
your approach is resulting in cleaner code (although more code lines;).
Yes, there are always compromises one has to make when coding. 😉
|
I just don't like the idea of having the white keys highlighted by default. If I'd want to have them all highlighted, I'd mark the C major scale in the scale settings. Maybe just highlight all of the C keys (if the goal is better orientation in the piano-roll)? This is what it looks when you highlight the C major scale: |
|
@Umcaruje I did not know that functionality before. I agree that always highlighting the white keys leads to rather messy results when that feature is enabled especially with a scale that's different from C major. The following picture shows a highlighted C harmonic minor scale with the C scale enabled as well: What do you think about switching to a rather subtle highlighting like in the screenshots above? Last but not least, I think that the scale highlighting feature is hidden too deep. I knew from @Umcaruje's screenshot that it somehow must be possible to enable the highlighting. When I then switched the scale combo box nothing happened. From a usability point of view that's not a good thing in my opinion. I had to use the code to find out that there is a context menu available for the keyboard keys and that it's somehow connected to the scale and chord combo boxes. Having another combo box that lists all 12 notes would be more intuitive in my opinion. The initial state would be "C" and "None". If you then select a scale from the combo box, e.g. "major", it would highlight C major. I know that the piano roll is space constrained already. However, that might be solved by using movable tool bars in the piano roll dialog and perhaps giving it a menu as well because it provides lots of functionality. |
|
@michaelgregorius Absolutely marvelous! This will help a lot of - no really every new-comer! |
|
Here's what the C harmonic minor scale would look like with subtle highlighting and the default highlighting of the C major scale disabled: We could also consider making the highlighting color a property of the piano roll so that it can be styled via style sheets. |
|
Some more images. 😉 I have played around with movable toolbars for the piano roll because I know that there have been complaints that it is hard to use on size constraint displays. This is what I came up with: What you see is the default layout of the toolbars which saves horizontal space by putting the "Zoom and note controls" below the other toolbars. The toolbars can be moved but their positions are not saved. I have also disabled floating toolbars, i.e. they will always stay inside the window (top, bottom, left, right). Any opinions? Shall I commit and push the changes on top of this pull request? |
+1 on both those things. I think the toolbar breakdown thing should really be a PR/Issue of its own, since we don't really want to have that many conversations on the same issue :) |
😮 |
|
@Umcaruje Done! I have created #2286 to document the changes and #2287 to implement them. @tresf This is all done using stuff that's already available from Qt! If you look at the code changes you will see that it was a rather low hanging fruit. There is some not so nice code concerning |
I would like to have more contrast -How does it look, if you have low volume on the notes.
👍 ! - If thats made, then everyone could choose contrast/ colors as liked : Big support to this! |
|
@musikBear Here it is with low volume notes: |
|
+1 on the borders staying bright.
|
|
This is how it looks with the borders always using the same color. Some of the notes are panned, some are very low volume and some very high volume. |
|
Looks a bit funky, but it does convey the volume and pan.
Unless it serves some other purpose, maybe the small box/handle/line on the
right could be removed/modified to de-clutter a bit? With the new curved
notes it looks/is off center and has weird empty space above and below it.
Apologies/sorry for the generous/excessive amount/number of slashes. :P
|
|
@michaelgregorius I like that edge |
|
How about using a thinner and slightly shorter line? @Spekular I did not change the volume and panning drawing code so it's the same style as before. I only made the outline color constant and altered the handles. No/problem/with/the/slashes! 😉 |
|
@michaelgregorius shorter and thinner definitely looks better imo :)
As for the pan/volume I know they're that way now, I was just thinking of
alternatives. I guess it was a bit off topic :p
|
|
Pushed the latest changes which correspond to the state shown in the last screenshot above. |
|
@michaelgregorius what's keeping us from squashing and committing this? I think this is terrific and a well needed addition. P.S. Administrator's note.... If you merge this yourself, please add it to the 1.2.0-RC1 release notes here: https://github.com/LMMS/lmms/releases Note: This 1.2.0-RC1 is a draft (and thus non-admins can't see it), and we must keep it that way or Travis will fire a build an put it on our homepage! 👍 |
|
@tresf, @Wallacoloo Is there something wrong with the master branch? I wanted to update my master branch to squash and merge this feature but the git pull resulted in a merge conflict in my repo although it should result in a fast forward. Also, if I look at the master branch here on GitHub the state looks rather old. For example it only shows two commits for today and the next commits are from August 26. My merge from yesterday is completely missing. Is this the same for everyone else as well? Edit: This is the current state shown in my fork: @tresf Have you force pushed an older tree or something like that with the improved Japanese translation (72d13ed)? |
|
@michaelgregorius better set aside a clone of your local repository in case something did go wrong - that way we can still restore it. Perhaps something went wrong merging #2339? I noticed that @andrewrk was pushing his commits to a separate branch in the lmms repository, rather than a branch in his own repository, and every time he pushed a new commit I also had merge conflicts. Also, there's no commit message in github's log for that merge. That's the only non-ordinary thing that's happened recently, although it doesn't seem like it would cause issues. |
|
@michaelgregorius @Wallacoloo I believe I caused this when I did a squash for the Japanese language translations. I'm not sure how this was possible, I only squashed the 4 commits. This is bad and I'll need help to fix this. Rewriting history is very bad on master and I knew this and I previewed my changes before pushing them but I think it wiped out history. F***. |
|
Going through the closed PRs, sorted by recently updated, we should be good if we take @michaelgregorius's master, and cherry-pick the following commits onto it: Although at the moment, @michaelgregorius is missing 5 commits from lmms' master, so that's at least 2 that are unaccounted for... |
|
Ok, done. Can you take a look now? |
|
@Wallacoloo yeah 72d13ed was the problem child, so I'm hesitant to touch that one. I'll just leave the unsquashed commits out there. The other two can be cherry picked now, but first I'd like to get a sanity check. |
|
Ok. Done. how about now? P.S. Instead of cherry-picking (I wasn't having luck one-by-one), I instead told git he was upstream and re-based against his. |
|
@tresf Seems to be ok now. 😃 |
|
@tresf did you get 2aef279 and 232c65c (from #2285 (comment))? (I'd checkout lmms & grep the commit log, but I don't have those tools handy). |
|
@Wallacoloo no, not yet. Not sure how to grab them yet. |
|
Never-mind, you provided the correct hashes, I'll try those instead. Edit No dice |
michaelgregorius
force-pushed
the
piano-roll-improvements
branch
from
6e05a6d to
6aae05f
Compare
|
@tresf then in your local repository, you'll have to add the associated remotes from those two PRs, fetch their branches, and then cherry-pick the two commits onto your master. Then push your master up to github (this shouldn't require and rewriting of history). If you can't cleanly cherry-pick the commits, you'll have to merge the branches locally, and then push master to github. |
|
@Wallacoloo done for #2045 via 571e4fd but now a new garbage branch is showing up called For #2140, it's parent branch was deleted... not sure how to merge that one in. |
|
Ok... got it via dff7e3e git fetch origin pull/2140/head:zonkytemp
git cherry-pick 2aef279Wipes sweat from forehead. Now to delete this garbage branch I mysteriously created... :) P.S. @michaelgregorius thanks for letting us use this PR for convo. |
I certainly did not force push master. I force pushed the branch I was working on, which is common git practice. You had merge conflicts because I was keeping the pull request clean, so every time you needed to get new code from me you had to delete your branch (or reset --hard it) before pulling. I would never do such a thing on master branch.
It's right here: 799f830 |
|
@andrewrk I certainly did not mean to accuse you of anything (I apologize if I came off that way) - I was trying to find any possible source of the error. I tried to make it extra clear there was no blame there by saying "[Merging #2339] doesn't seem like it would cause issues."
Thankfully, yes - @tresf was able to recover everything. At the time, that commit and many others were not present in the lmms repository. |
I wish github had a non-smiling blushing emoticon right now... |
Draws note labels on all (white) keys when selecting to do so in the
preferences ("Enable note labels in piano roll"). The old rather messy
implementation that drew them all over the place has been removed.
When rendering note names on the keyboard keys the C notes are rendered
in a darker color than the other ones. Horizontal lines which do not
correspond to the C key are now also rendered in a more subtle way to
give more prominence to the start of an octave.
The user selected scale is now highlighted in a more subtle way.
The note borders are not toned down in relation to the volume anymore.
The handles on the right side of each note have been made slimmer and
shorter.
michaelgregorius
force-pushed
the
piano-roll-improvements
branch
from
6aae05f to
2ea7208
Compare
Merge PianoRoll improvements (note on keys, subtle highlight, note rendering)
👍 |
No worries. I just wanted to make it clear that I would not misuse collaborator privileges like that.
Glad to hear the problem is resolved :-) |
Draws note labels on all (white) keys when selecting to do so in the
preferences ("Enable note labels in piano roll"). The old rather messy
implementation that drew them all over the place has been removed.
Furthermore, the lanes of the white keys are now slightly highlighted in
the piano roll.