Old 05-09-2019, 02:43 PM   #1
Edgemeal
Human being with feelings
 
Edgemeal's Avatar
 
Join Date: Apr 2016
Location: ASU`ogacihC
Posts: 3,913
Default 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
Edgemeal is offline   Reply With Quote
Old 05-09-2019, 05:57 PM   #2
nofish
Human being with feelings
 
nofish's Avatar
 
Join Date: Oct 2007
Location: home is where the heart is
Posts: 12,096
Default

Quote:
Originally Posted by Edgemeal View Post
v5.977+dev0509 - May 9 2019
+ API: skip hidden automatic edge attachment points when counting/getting/setting points in automation items
Pet peeve fix. Thanks a lot!
On first test it looks like this squashes a number of bugs:
- GetEnvelopePoint() returns nonexistent points if AI connected to underl. env.
- CountEnvelopePointsEx() not returning nr. of points in AI
- GetEnvelopePointEx() timeOut breaks if no start edge point.

So far I couldn't reproduce any of these with this version. I keep trying...
nofish is offline   Reply With Quote
Old 05-10-2019, 02:58 AM   #3
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,646
Default

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.
Tale is offline   Reply With Quote
Old 05-10-2019, 04:48 AM   #4
mccrabney
Human being with feelings
 
mccrabney's Avatar
 
Join Date: Aug 2015
Posts: 3,671
Default

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.
__________________
mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
mccrabney is online now   Reply With Quote
Old 05-10-2019, 05:36 AM   #5
Meo-Ada Mespotine
Human being with feelings
 
Meo-Ada Mespotine's Avatar
 
Join Date: May 2017
Location: Leipzig
Posts: 6,622
Default

Quote:
Originally Posted by nofish View Post
Pet peeve fix. Thanks a lot!
On first test it looks like this squashes a number of bugs:
- GetEnvelopePoint() returns nonexistent points if AI connected to underl. env.
- CountEnvelopePointsEx() not returning nr. of points in AI
- GetEnvelopePointEx() timeOut breaks if no start edge point.

So far I couldn't reproduce any of these with this version. I keep trying...
Nice!
__________________
Use you/she/her.Ultraschall-Api Lua Api4Reaper - Donate, if you wish

On vacation for the time being...
Meo-Ada Mespotine is online now   Reply With Quote
Old 05-10-2019, 07:06 AM   #6
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,714
Default

Quote:
Originally Posted by mccrabney View Post
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.
juliansader is offline   Reply With Quote
Old 05-10-2019, 08:44 AM   #7
mccrabney
Human being with feelings
 
mccrabney's Avatar
 
Join Date: Aug 2015
Posts: 3,671
Default

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
__________________
mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.

Last edited by mccrabney; 05-10-2019 at 08:51 AM.
mccrabney is online now   Reply With Quote
Old 05-10-2019, 04:00 PM   #8
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,714
Default

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
juliansader is offline   Reply With Quote
Old 05-10-2019, 10:48 PM   #9
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

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.
EvilDragon is offline   Reply With Quote
Old 05-11-2019, 02:57 AM   #10
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

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.
gofer is offline   Reply With Quote
Old 05-11-2019, 03:51 AM   #11
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
Default

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:

__________________
My Reascripts forum thread | My Reascripts on GitHub
If you like or use my scripts, please support the Ukraine: Ukraine Crisis Relief Fund | DirectRelief | Save The Children | Razom
_Stevie_ is offline   Reply With Quote
Old 05-11-2019, 04:10 AM   #12
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

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.
gofer is offline   Reply With Quote
Old 05-11-2019, 04:22 AM   #13
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
Default

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
__________________
My Reascripts forum thread | My Reascripts on GitHub
If you like or use my scripts, please support the Ukraine: Ukraine Crisis Relief Fund | DirectRelief | Save The Children | Razom
_Stevie_ is offline   Reply With Quote
Old 05-11-2019, 04:41 AM   #14
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

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 ).
gofer is offline   Reply With Quote
Old 05-11-2019, 04:48 AM   #15
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
Default

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...)
__________________
My Reascripts forum thread | My Reascripts on GitHub
If you like or use my scripts, please support the Ukraine: Ukraine Crisis Relief Fund | DirectRelief | Save The Children | Razom
_Stevie_ is offline   Reply With Quote
Old 05-11-2019, 05:25 AM   #16
mccrabney
Human being with feelings
 
mccrabney's Avatar
 
Join Date: Aug 2015
Posts: 3,671
Default

Quote:
Originally Posted by EvilDragon View Post
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.
__________________
mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
mccrabney is online now   Reply With Quote
Old 05-11-2019, 05:33 AM   #17
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

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.
gofer is offline   Reply With Quote
Old 05-11-2019, 06:19 AM   #18
mccrabney
Human being with feelings
 
mccrabney's Avatar
 
Join Date: Aug 2015
Posts: 3,671
Default

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
__________________
mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.

Last edited by mccrabney; 05-11-2019 at 06:38 AM.
mccrabney is online now   Reply With Quote
Old 05-11-2019, 07:20 AM   #19
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

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.
gofer is offline   Reply With Quote
Old 05-11-2019, 07:48 AM   #20
Vagalume
Human being with feelings
 
Join Date: Nov 2015
Posts: 604
Default

Quote:
Originally Posted by EvilDragon View Post
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).
Vagalume is offline   Reply With Quote
Old 05-11-2019, 10:32 AM   #21
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

Quote:
Originally Posted by Vagalume View Post
I am with ED (in this one).
Agreed. The only problem with the theme tweaker solution would be getting gradient colors.
srdmusic is online now   Reply With Quote
Old 05-11-2019, 11:20 AM   #22
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

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.
gofer is offline   Reply With Quote
Old 05-11-2019, 11:55 AM   #23
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Well, you don't necessarily need to type RGB in when you can pick the color from the palette...
EvilDragon is offline   Reply With Quote
Old 05-11-2019, 12:07 PM   #24
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

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.
gofer is offline   Reply With Quote
Old 05-11-2019, 12:17 PM   #25
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

It's still not consistent with how the rest of colors are defined.
EvilDragon is offline   Reply With Quote
Old 05-11-2019, 12:18 PM   #26
xpander
Human being with feelings
 
xpander's Avatar
 
Join Date: Jun 2007
Location: Terra incognita
Posts: 7,670
Default

Quote:
Originally Posted by gofer View Post
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.
xpander is offline   Reply With Quote
Old 05-11-2019, 12:18 PM   #27
Commala
Human being with feelings
 
Join Date: Feb 2014
Posts: 615
Default

Quote:
Originally Posted by gofer View Post
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 View Post
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.
Commala is offline   Reply With Quote
Old 05-11-2019, 02:25 PM   #28
mccrabney
Human being with feelings
 
mccrabney's Avatar
 
Join Date: Aug 2015
Posts: 3,671
Default

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
__________________
mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
mccrabney is online now   Reply With Quote
Old 05-11-2019, 02:33 PM   #29
Commala
Human being with feelings
 
Join Date: Feb 2014
Posts: 615
Default

Quote:
Originally Posted by mccrabney View Post
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.
Commala is offline   Reply With Quote
Old 05-11-2019, 02:52 PM   #30
mccrabney
Human being with feelings
 
mccrabney's Avatar
 
Join Date: Aug 2015
Posts: 3,671
Default

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
__________________
mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.

Last edited by mccrabney; 05-11-2019 at 03:15 PM.
mccrabney is online now   Reply With Quote
Old 05-11-2019, 04:53 PM   #31
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,714
Default

Quote:
Originally Posted by mccrabney View Post
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.)
juliansader is offline   Reply With Quote
Old 05-11-2019, 05:33 PM   #32
mccrabney
Human being with feelings
 
mccrabney's Avatar
 
Join Date: Aug 2015
Posts: 3,671
Default

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.
__________________
mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.

Last edited by mccrabney; 05-11-2019 at 06:33 PM.
mccrabney is online now   Reply With Quote
Old 05-11-2019, 06:23 PM   #33
cool
Human being with feelings
 
Join Date: Dec 2017
Location: Sunny Siberian Islands
Posts: 958
Default

Quote:
Originally Posted by Commala View Post
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.
cool is online now   Reply With Quote
Old 05-11-2019, 08:23 PM   #34
Commala
Human being with feelings
 
Join Date: Feb 2014
Posts: 615
Default

Quote:
Originally Posted by gofer View Post

...

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.
Commala is offline   Reply With Quote
Old 05-13-2019, 07:41 AM   #35
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

Quote:
Originally Posted by cool View Post
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
srdmusic is online now   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 07:52 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.