|
|
|
05-09-2019, 02:43 PM
|
#1
|
Human being with feelings
Join Date: Apr 2016
Location: ASU`ogacihC
Posts: 3,913
|
v5.977+dev0509 - May 9 2019
v5.977+dev0509 - May 9 2019
+ API: GetSetMediaTrackInfo() returns updated value when setting mute/selection
+ API: skip hidden automatic edge attachment points when counting/getting/setting points in automation items
+ Resampler: Added SSE2-optimized sinc calculation (from Theo Niessink)
# MIDI editor: restore option to edit CC/velocity only when mouse is near event [p=2131950]
Full changelog / Latest pre-releases
|
|
|
05-10-2019, 02:58 AM
|
#3
|
Human being with feelings
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,646
|
Quote:
+ Resampler: Added SSE2-optimized sinc calculation (from Theo Niessink)
|
FWIW: Offline rendering 44.1 kHz stereo to a 96 kHz 24-bit WAV file in Extreme HQ mode seems to have improved from 6.9x to 8.7x here (comparing v5.977/x64 with dev0509).
I see no immediate improvement when doing the same in Medium mode, but I guess that's because then writing the WAV file is the bottleneck, not resampling.
The difference in Extreme HQ mode peaks at -123 dB, but that's likely because of the earlier optimization for whole ratios/common rates. In Medium mode there is no (measurable) difference.
|
|
|
05-10-2019, 04:48 AM
|
#4
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,671
|
as we continue the colormap conversation, i've not found any way to control neither the outline nor "selected" color of color-by-track midi. color-by-track currently just uses a brighter version of the track color to border notes/velocity flags. this makes for a very unclear distinction between what midi is selected vs unselected.
if i could, i'd make all unselected midi have a black outline, and all selected midi have a white outline. i believe this will work, even on white and black tracks, due to existing shading drawn from colormaps (white tracks' midi notes appear greyish when unselected, but brighten when selected -- just not enough to be immediately clear, esp from far zoomouts).
i started making a licecap "game" to illustrate how hard it is to determine which color-by-track notes are selected vs unselected. the licecap title had a 5 second title intro, and then a 1 second view of a track with a bunch of midi notes, some of which were selected. (i scrapped the licecap, because it came across as patronizing and that wasn't the intention)
anyway, the point was that at a 1 second glance, it was difficult to tell. in my opinion, anything that takes more than a cursory (or even peripheral) glance to determine its state needs more contrast.
|
|
|
05-10-2019, 05:36 AM
|
#5
|
Human being with feelings
Join Date: May 2017
Location: Leipzig
Posts: 6,622
|
Quote:
Originally Posted by nofish
|
Nice!
|
|
|
05-10-2019, 07:06 AM
|
#6
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Quote:
Originally Posted by mccrabney
if i could, i'd make all unselected midi have a black outline, and all selected midi have a white outline. i believe this will work, even on white and black tracks, due to existing shading drawn from colormaps (white tracks' midi notes appear greyish when unselected, but brighten when selected -- just not enough to be immediately clear, esp from far zoomouts).
|
If borders use a different color than the actual track color, it may be difficult to tell the source track at a glance, especially if all tracks use the same border colors, or if the events are densely drawn from far zoomouts.
|
|
|
05-10-2019, 08:44 AM
|
#7
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,671
|
i manage that by making other tracks transparent - and by entering specific track midi via dedicated action. that way, there's no question.
edit, an alternative workaround would be the ability to specify "selected midi" fill color, but that element in the theme is overriden by midi colormap and i can't figure out how to avoid that
Last edited by mccrabney; 05-10-2019 at 08:51 AM.
|
|
|
05-10-2019, 04:00 PM
|
#8
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Perhaps, when in color by track/item/source mode, lollipops and notes should use the same *hue* as the track/item/source, but with different *luminosity* when selected vs unselected? These can even be theme settings:
* MIDI event luminosity - unselected
* MIDI event luminosity - selected
|
|
|
05-10-2019, 10:48 PM
|
#9
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
|
That sounds like a pretty good solution.
I would rather suggest to deprecate the colormap and just make all those colors available in the Theme Tweaker. I'm not sure why we need two different ways of defining which colors are used in different areas of the program. it is not consistent.
|
|
|
05-11-2019, 02:57 AM
|
#10
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
re colormap:
The most important visual things for me when working in the MIDI editor is to be able to know at all times and at a glance
- whether an event is selected or not
- which events are on same channels (even if some are selected and some not)
- whether an event is on the active item or on secondary items.
To be able to recognize channels has become of huge importance when I began to do orchestral stuff, but even more so since I use MPE devices.
I switch to track colors only when I want an overview about what the different instrument groups are doing and how they relate to each other. Any editing is done using channel colors here (sometimes when I am concentrating on velocities, I use those colors as well, but not so much).
So a white border on everything selected is out of the question for me, because right now that means any selected event in the CC lane would be white and I can't tell which channel they are on. That would only work for me if selected CC/velocity events used both, border and body color.
Maybe that would be worth trying on the circles. Right now they just grow a pixel (and can use a different color). Tint the "growing ring" with border color (row 130) and use row 65 (or 129 if that's better with the default colormap) for selected circle's body color?
It would help me tremendously in my mission to create 16 distinguishable colors for channels, because I could then use all 3 aspects (hue/saturation/brightness) for that alone and the border color for selection status.
One other thing that's currently not good is that CC events look the same on active and editable items. And CC lane background color doesn't have an "out of bounds" color. There's important information missing.
Btw, I am super happy to see that this pre has gone back to using row 1 for unselected CC lane events Please keep that.
|
|
|
05-11-2019, 03:51 AM
|
#11
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
Interesting post gofer. For selected events: how about an outline of the current event colour and the inner colour changes to a darker tone?
Edit: I hate to say that, but something in the vain of logic:
|
|
|
05-11-2019, 04:10 AM
|
#12
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
I still have a weak spot for Logic
I tried something like that, because I like the look and it's very obvious. But I found that (IMO) this only works because that colored border on selected events is itself surrounded by a dark frame. In Reaper, depending on the color, the thin border line can tend to blend in with the background.
EDIT:
And,it doesn't really help with CC/velocity.
Last edited by gofer; 05-11-2019 at 04:31 AM.
|
|
|
05-11-2019, 04:22 AM
|
#13
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
So, a thicker outline boarder would be the solution, I guess!
EDIT: no true, for CC and velocity this doesn't help. But we gotta start somehwere :P
|
|
|
05-11-2019, 04:41 AM
|
#14
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
Yes, it's a difficult endeavour . Not least because everyone has different requirements.
I'd love to have two seperate pixels worth of outline for notes, but for CC that's probably not feasible at all. But I still hope they decide for seperate border/body colors on CC/velocity circles (just to plug that idea once more ).
|
|
|
05-11-2019, 04:48 AM
|
#15
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
Different requirements, yes. But to be honest, eventhough I don't use VSTis on different channels, I like the idea to have a clear distinction between all those different events. It just makes this all consistent and we don't run into trouble, when using one of these workflows (editing many items at once, editing many channels at once...)
|
|
|
05-11-2019, 05:25 AM
|
#16
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,671
|
Quote:
Originally Posted by EvilDragon
That sounds like a pretty good solution.
I would rather suggest to deprecate the colormap and just make all those colors available in the Theme Tweaker. I'm not sure why we need two different ways of defining which colors are used in different areas of the program. it is not consistent.
|
bingo.
i am not one to shy away from dabbling in the mechanics, but having to edit an arcane PNG to define some more fundamental color choices seems a little much.
|
|
|
05-11-2019, 05:33 AM
|
#17
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
Not sure I understand correctly, but wouldn't replacing the colormap in the theme editor dialog mean approximately 300 new entries (plus some new gradient overlay feature) in that list?
As an example, look at the envelope colors section. If I had the choice between tweaking them using the color picker dialog from within the theme tweaker and a single png in an image editor, I'd personally go with the image editor any day. Much less clicking between two dialog windows and I can even make it so that I see the colors on top of my personal envelope lane background color while tweaking.
Last edited by gofer; 05-11-2019 at 05:47 AM.
|
|
|
05-11-2019, 06:19 AM
|
#18
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,671
|
gradients are fine uses for such a PNG (though gimp and Photoshop let users define gradients by simply picking 2 colors). it's the 1 pixel wide stuff (note borders etc) that belong in the theme editor.
edit, or maybe all of our combined confusion is indication enough that the process needs simplification
Last edited by mccrabney; 05-11-2019 at 06:38 AM.
|
|
|
05-11-2019, 07:20 AM
|
#19
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
My confusion was about deprecating the colormap. I understand your thinking, but am not sure I would want to edit at two different places when designing the looks of one type of thing, say, MIDI notes.
Actually I personally am in favour of even more diversity in the colormap (separate sections for CC/velocity, notes and both of these event types in active, editable, not editable items. Not necessarily simplification.
I am very much willing to put work into the matter if that means I can make stuff look more informative and more consistent.
EDIT:
That's for pretty much the same reason that I would like seperate entries for, say, MIDI editor ruler and CC lane background colors. Double/triple usage of the same adjuster (is that a word, don't think so, but anyway) for different things is so very restrictive.
What I am not a fan of it to have to find out which row of the colormap does what (example: colors taken from the second row of the image for secondary item notes, that I found out by chance when searching for unselected velocity color... that kind of stuff should be documented somewhere to simplify theming .
Last edited by gofer; 05-11-2019 at 07:36 AM.
|
|
|
05-11-2019, 07:48 AM
|
#20
|
Human being with feelings
Join Date: Nov 2015
Posts: 604
|
Quote:
Originally Posted by EvilDragon
That sounds like a pretty good solution.
I would rather suggest to deprecate the colormap and just make all those colors available in the Theme Tweaker. I'm not sure why we need two different ways of defining which colors are used in different areas of the program. it is not consistent.
|
I am with ED (in this one).
|
|
|
05-11-2019, 10:32 AM
|
#21
|
Human being with feelings
Join Date: Dec 2016
Posts: 876
|
Quote:
Originally Posted by Vagalume
I am with ED (in this one).
|
Agreed. The only problem with the theme tweaker solution would be getting gradient colors.
|
|
|
05-11-2019, 11:20 AM
|
#22
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
But you are aware that the colormap currently is setting 2x 128 gradients for velocity, 2x 16 gradients for channels, 2x 12 gradients for pitch plus two gradients for muted events? That's 314 gradients.
On the non-gradient front it currently sets 314 outline colors, 157 unselected CC/velocity colors and 314 body colors for notes in secondary items.
You'd be blowing up the theme tweaker quite a bit. And for each setting you'll have to enter the color picker one by one, type in the desired three numbers, check if the color is good, go back and retweak... I just can't believe you really want to suffer that much.
|
|
|
05-11-2019, 11:55 AM
|
#23
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
|
Well, you don't necessarily need to type RGB in when you can pick the color from the palette...
|
|
|
05-11-2019, 12:07 PM
|
#24
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
Well, it takes me probably less time to create a complete and neat colormap than to create a palette with 16 useful colors... Still have to assign them to all the entries. And if I decide to use a different palette I can easily globally tweak in an image editor while I'd have to go one-by one all over again in the tweaker.
|
|
|
05-11-2019, 12:17 PM
|
#25
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
|
It's still not consistent with how the rest of colors are defined.
|
|
|
05-11-2019, 12:18 PM
|
#26
|
Human being with feelings
Join Date: Jun 2007
Location: Terra incognita
Posts: 7,670
|
Quote:
Originally Posted by gofer
You'd be blowing up the theme tweaker quite a bit. And for each setting you'll have to enter the color picker one by one, type in the desired three numbers, check if the color is good, go back and retweak... I just can't believe you really want to suffer that much.
|
Given that there are currently about 300 entries in the theme tweaker, that would go about 4 times bigger if all the colormap options would be added in there. That is a lot for sure.
Picking colors from the palette can ease setting somewhat and Filter may help searching the list. But I would think with all the possible new entries, theme tweaker would also have to be sectionalized more clearly? Section headings at least? And/or allowing Filter to show just a specified section?
---
Oh, and thanks for the secondary item note color tip, Gofer. I had no idea where to set that up. Better colormap documentation would indeed be nice.
|
|
|
05-11-2019, 12:18 PM
|
#27
|
Human being with feelings
Join Date: Feb 2014
Posts: 615
|
Quote:
Originally Posted by gofer
Actually I personally am in favour of even more diversity in the colormap (separate sections for CC/velocity, notes and both of these event types in active, editable, not editable items. Not necessarily simplification.
I am very much willing to put work into the matter if that means I can make stuff look more informative and more consistent.
|
I absolutely agree with this.
Quote:
Originally Posted by EvilDragon
I would rather suggest to deprecate the colormap and just make all those colors available in the Theme Tweaker. I'm not sure why we need two different ways of defining which colors are used in different areas of the program. it is not consistent.
|
I like this for the control it would provide, and surely we would be able to do anything we needed for any type of theme and colour paradigm if this were implemented.
However, I don't think it is really necessary to deprecate the colour map. The colour map has fulfilled its purpose just fine up until this point. The new visual implementations of CCs and velocity lollipops are what require a new approach, and I firmly believe that we should concentrate on this and this only. Here is what I think is the best method:
==============
First, there is the issue of compatibility with older themes. Schwa has said that priority must be given to how the v5 theme would be displayed with the adoption of any new approach. At first I thought of simply redefining rows of the existing colour map to be used to draw only CCs and velocities. However, this could lead to unpredictable results with old themes. With this in mind, I believe that the MIDI note colour map should be used how it is in the current release, where particular lines are used to colour CCs and velocities. This gives us a functional baseline that old themes can use regardless of whether they have been updated to take advantage of the new features. Nothing is broken.
Then, simply create a second colour map for CCs and velocities only (MIDI_vel_CC_colour_map.png), that can be included in new themes going forward. If it is present then the theme will use it, otherwise it will fall back to original colour map. This way, we can make use of the convenience and fine-grained control provided by the colour map approach, without compromising the display of either old themes or how notes are displayed. Including new pngs for new features has been done before and it works fine, this was done for the latch preview feature for example. Let's allow the MIDI note colour map to continue to be dedicated to that; CCs and velocities are different enough in appearance and function that they call for their own map.
Next let's define the components of the new elements. There are four: velocity head, velocity stem, CC point and CC fill.
In this new colour map, let us have specific control over all of these components separately, by giving each of them their own dedicated row. So that would be eight rows altogether (one for each of the components in both upper and lower halves of the map, corresponding to selected/unselected). I think that CCs and velocities will be adequately rendered without needing any vertical columns as part of their definitions, but some may also like to have a vertical gradient for CCs for example. Having a separate colour map for velocities and CCs would enable us to do this for CCs without affecting how notes are drawn. Additional rows could be used to define outlines for velocity heads, stems, and CC points as well. I would prefer this additional control, and again creating a brand new png map would allow this flexibility without creating conflicts with note rendering in old themes.
The CC fill could additionally have a dedicated blend/alpha dialog in the theme tweaker to define the degree of transparency when selected and unselected. This same implementation could be extended to give transparency/or blend mode control of the other three components as well if people thought that was necessary, but personally I do not.
Finally, provide an option in the theme tweaker whether or not to change line weight of the velocity stems based on selection.
=========
Adding a new colour map, and including new theme tweaker controls may seem more complex at first glance, but the fact is that themers are used to this kind of complexity. There are dozens of examples of quirky and arcane implementations in the themeing process, but the end result is what matters, and thus far the control we have over theme elements has been adequate and provides good results. Of course, more fine-grained control over more facets of Reaper's interface is always welcome, and when people have criticized Reaper's GUI or themeing limitations it is usually only for want of additional control.
So again, I say that we simply get new methods of control to go along with new theme elements. Let's not fix what isn't broken. Use the colour map for what it is good for, and expand on that in a way that allows for greatest flexibility. I believe that my suggestion above would enable satisfactory control for any themeing approach.
Last edited by Commala; 05-11-2019 at 12:32 PM.
|
|
|
05-11-2019, 02:25 PM
|
#28
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,671
|
Quote:
The new visual implementations of CCs and velocity lollipops are what require a new approach, and I firmly believe that we should concentrate on this and this only.
|
well... not quite, as track-colored midi (notes) has major visibility issues that have inadvertently gotten worse due to the recent color by source bug fix.
as far as I can tell, users have a great deal of configurability for every other "color by" mode, with the exception of track color. by now I'm guessing that I'm correct to say that there is no way to control color-by-track's border OR selected color.
I truly don't care much as to how this gets addressed, even if I have to enter color codes ala html
|
|
|
05-11-2019, 02:33 PM
|
#29
|
Human being with feelings
Join Date: Feb 2014
Posts: 615
|
Quote:
Originally Posted by mccrabney
well... not quite, as track-colored midi (notes) has major visibility issues that have inadvertently gotten worse due to the recent color by source bug fix.
as far as I can tell, users have a great deal of configurability for every other "color by" mode, with the exception of track color. by now I'm guessing that I'm correct to say that there is no way to control color-by-track's border OR selected color.
I truly don't care much as to how this gets addressed, even if I have to enter color codes ala html
|
Truly, I remember noticing that colour by source thing a while back as well. You're right that this is certainly something also worthy of attention, I didn't mean to imply otherwise by my use of that rhetorical device.
I don't actually know how Reaper draws the notes but I speculated in the thread where that bug was reported that it may be a bit trickier to fix that issue than one might assume. At the time I suggested a monochrome column in the MIDI note colour map that could be colourized according to the track/source colours, so that we get a consistent look, but that was really just a shot in the dark as far as whether that is even technically possible with the way that colouring mode is implemented.
|
|
|
05-11-2019, 02:52 PM
|
#30
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,671
|
haha. it was your post on this subject that clarified some of my confusion earlier, so thanks. also, i use one of your themes (vitalker tweak + mccrabney tweak) and really enjoy it - selected notes in track-colored midi is essentially my only theme or graphical user interface issue in all of REAPER.
Julian had a good idea with the luminosity option to indicate selected status, but ideally, I could set all selected midi to one specific, track independent color that isn't used to color any tracks. this might be ugly, and I wouldn't recommend it for default, but by god you'd know for a fact that all bright pink midi is selected.
imo having different tracks' colors result in different "selected" color seems more an appeal to graphic designers rather than intense users. totally cool to be that way for the default theme though
Last edited by mccrabney; 05-11-2019 at 03:15 PM.
|
|
|
05-11-2019, 04:53 PM
|
#31
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Quote:
Originally Posted by mccrabney
Julian had a good idea with the luminosity option to indicate selected status, but ideally, I could set all selected midi to one specific, track independent color that isn't used to color any tracks.
|
Whatever the hue, a maximum luminosity is pure white, and a minimum luminosity is pitch black, so perhaps either these extremes can serve as the independent color?
(The raison d'être for "Color by track" is to distinguish tracks by color, so personally I would not find it helpful if selected events from different tracks are all the same color.)
|
|
|
05-11-2019, 05:33 PM
|
#32
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,671
|
viable option. I'm having a hard time visualising how that would work with my black midi track and white midi track. I should probably just use other colors for those.
this gets very workflow dependent very fast. one "selected" color choice would work for me because i don't often edit multiple tracks at once in the midi editor (each track/channel's midi editor is opened by dedicated action, so it's easy to bounce back and forth between tracks). in addition, i wouldn't need to expect a different "selected" color on each track.
Last edited by mccrabney; 05-11-2019 at 06:33 PM.
|
|
|
05-11-2019, 06:23 PM
|
#33
|
Human being with feelings
Join Date: Dec 2017
Location: Sunny Siberian Islands
Posts: 958
|
Quote:
Originally Posted by Commala
I absolutely agree with this.
Then, simply create a second colour map for CCs and velocities only (MIDI_vel_CC_colour_map.png), that can be included in new themes going forward. If it is present then the theme will use it, otherwise it will fall back to original colour map. This way, we can make use of the convenience and fine-grained control provided by the colour map approach, without compromising the display of either old themes or how notes are displayed. Including new pngs for new features has been done before and it works fine, this was done for the latch preview feature for example. Let's allow the MIDI note colour map to continue to be dedicated to that; CCs and velocities are different enough in appearance and function that they call for their own map.
|
I think this can be done for the main color map, but fully switch to Theme Tweaker: if midi_note_colormap.png exists, use its values. If not, take the values from Theme Tweaker.
|
|
|
05-11-2019, 08:23 PM
|
#34
|
Human being with feelings
Join Date: Feb 2014
Posts: 615
|
Quote:
Originally Posted by gofer
...
I'd love to have two seperate pixels worth of outline for notes, but for CC that's probably not feasible at all. But I still hope they decide for seperate border/body colors on CC/velocity circles (just to plug that idea once more ).
|
Whoa, missed this suggestion earlier. Again I completely agree with you. I think if a new colour map was to be used, the separate border colours on CC/velocity circles could be included there. Possibly even the second note border? I'd like to see a second note border as well, then things could look really sharp. I liked that you posted the screenshot of Logic so everyone can see how that would look.
Maybe adding the definition for the second note border in the CC/velocity colour map would be too illogical, it's preferable perhaps to just change the MIDI note colour map and add the definitions for the second border there... and then to avoid any compatibility issues, enable display of the second border by an option in the theme tweaker, off by default.
And I hope it makes sense what I'm saying about a second colour map, regarding the outlines.
So row by row, a new colour map dedicated to velocity lollipops and CCs could look like this:
1 velocity head unselected
2 velocity head outline unselected
3 velocity stem unselected
4 velocity stem outline unselected
3 CC point unselected
4 CC point outline unselected
5* CC fill unselected
6 velocity head selected
7 velocity head outline selected
8 velocity stem selected
9 velocity stem outline selected
10 CC point selected
11 CC point outline selected
12* CC fill selected
Plus rows for second note border selected/unselected ?
Columns would be identical to MIDI note colour map.
* Rows 5 and 12 could be expanded to included a vertical section that would allow gradients for the CC fills, which would be cool. The velocity stem section could also be expanded in this way, although personally I don't see any utility or aesthetic value in putting gradients on the velocity stems.
Any takers on a second colour map? They really are a breeze to edit, in comparison to theme tweaker entries, imo. Granted, you do need to unpack the theme and use a graphics editor when it comes to any png resources. But then, that's how we're already doing it.
Last edited by Commala; 05-11-2019 at 08:37 PM.
|
|
|
05-13-2019, 07:41 AM
|
#35
|
Human being with feelings
Join Date: Dec 2016
Posts: 876
|
Quote:
Originally Posted by cool
I think this can be done for the main color map, but fully switch to Theme Tweaker: if midi_note_colormap.png exists, use its values. If not, take the values from Theme Tweaker.
|
Yes please!!! +1
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 07:52 AM.
|