What I would like to do is be able to set the color of a key in the MidiKeyboardComponent.
I’ve not had luck with my searches. I’ve seen drawWhiteNote an drawBlackNote. They seem to have the parameters to do what I would like, but the actual API call to set the color eludes me.
I’m looking for something like
setColour( int keyNumber, juce::colourid);
Very high level thought but overriding those two methods, even though you have a color parameter, you can paint the color of your choice.
Overriding those two methods means you use the Graphics instance passed and actually draw the rectangle and color you have setup earlier in your code or dynamically figure it out based on some changed state.
Simply you could have a map that creates a relationship between the pitch and color, use that to draw the key’s color when asked.
The component ‘calls’ the two draw* methods.
Also, maybe there is Look & Feel for this, but still could accomplish the dirty way.
(I don’t know if the above is the correct way, never tried it)
Thanks for that.
Looking over the parameters, I see that I will need a “Graphics” object passed in.
It looks like I may need to override “Paint” and draw my Midi Keys there.
Does that sound like it makes sense?
Again, I have not actually used this component explicitly but I remember conversations around it.
https://docs.juce.com/master/classMidiKeyboardComponent.html
The methods already have a graphics passed.
virtual void drawWhiteNote (int midiNoteNumber, Graphics &g, Rectangle< float > area, bool isDown, bool isOver, Colour lineColour, Colour textColour)
virtual void drawBlackNote (int midiNoteNumber, Graphics &g, Rectangle< float > area, bool isDown, bool isOver, Colour noteFillColour)
Notice the &Graphics reference passed.
I would guess that if you want a custom layout of keys, then you would override paint() but just drawing keys, override the above and they should get called automatically from super’s paint() or elsewhere.
The MidiKeyboardComponent doesn’t seem to use LookAndFeel at all.
The drawWhiteNote and drawBlackNote get the colour as parameter provided.
That means you will have to override the paint() method, start by copying the original and change the code in the loop drawing to pick up your bespoke per-note-colour.
Why would this matter though, if you had your own map of pitch to color, you can just use that mapped pitch color in the method overrides.
Am I missing something?
Why would you need to override paint()?
… I guess I need to look at the code. 
I won’t edit the above, there is no pitch passed, my bad.
I was totally wrong, yes paint() is where it’s at!
Both will work. I just thought it’s the easier place.
Your suggestion would work if you just ignore the colour from the caller and use a new colour map you are adding.
Neither drawWhiteNote nor drawBlackNote is part of the public API, that means you are free to change the implementation at any place.
Thank Daniel, I’ll get right on that.
No worries, mate. I did get the gist of what you said.
I’ve been looking at code on GitHub. It looks like we’re all in agreement here.
Override Paint!
