This page covers:

• How colour works, in the context of Keysight
• Where colours are used
• What each colour mode does
• Some useful tricks to keep in mind when editing colours

What is colour?

R/G/B

Keysight, like most applications, internally considers colour as made up of Red, Green and Blue channels (RGB). Colours are described as a per-channel value between 0.00 - 1.00, with brightness (where used) multiplying these base values.

A colour of "orange" is therefore described as (1.0, 0.5, 0.0) within Keysight. If a brightness of 0.2 is applied on top of this, the orange colour functionally then becomes a rich brown and is (0.2, 0.1, 0.0).

H/S/V

Raw values for colour channels are not shown to the user. Instead, the Keysight colour picker shows colour externally as Hue, Saturation and Value. This is much more intuitive for human editing.

• Hue: this is the "pure" colour (top slider, above)
• Saturation: how much "colour" is in the colour (bottom left slider, above)
• Value: determines brightness (bottom right slider, above)

Any colour described as having zero Saturation will be simply greyscale, regardless of the Hue. Likewise, any colour with zero Value will simply be black.

Hex

The internal values in the R/G/B colour space are present in the colour picker as a hex code.

The first # character denotes that this is a hex code, and then each two characters in the hex code represent a channel: # FF / 88 / 00 = R / G / B.

Hex is called hex due to being in hexadecimal, or base 16. More information about how hex works can be found here➚, but the short version is that instead of counting from 0-9 and then incrementing to 10, hex counts 0-9 then A-F before incrementing to 10.

Therefore FF is the maximum value of a colour channel described in hex. The raw 0.00 - 1.00 channel value is multiplied by 255 before being rounded to the nearest integer

• #FFFFFF = pure white
• #FF0000 = pure red
• #0000FF = pure blue
• #FF8800 = orange (red, with a bit of green)

Why talk about this?

Knowing how colours are calculated internally often offers insight into how things end up looking in practice, as it is common to have colours multiplying against other colours within the RGB colour space. Also, knowing how hex codes work is just useful computer knowledge in general!

How is colour used?

Colour usage in Keysight comes in two forms:

• Static: just a colour, no extra behaviour
• Dynamic: uses this menu of options

Static colours are typically used by Scene elements like the Backdrop or Void colour. Dynamic colours are used by Effects such as Keypresses and Note objects.

In Basic menu mode(*), each element's colours are controlled by the single Colour menu (with the exception of Note object borders that are not emissive, which are kept black).

In Advanced menu mode(*), each element's colours are controlled locally to that element.

Dynamic colour modes

Static

Behaviour

Each new MIDI event uses the next colour slot for all elements spawned by that MIDI event. Given three colour slots: the first note-on event in Keysight will use slot 1, the second will use slot 2, the third will use slot 3, the fourth will use slot 1, etc.

Usage

This mode is great if you want a random distribution of static colours across repeated instances of an element.

Channel

Behaviour

Colour slot is chosen by element based on the MIDI event's channel(*).

Usage

This is an excellent mode for simple colours used to visualise different hands or different instruments without having to resort to full channel-to-preset mapping.(*)

Velocity

Behaviour

Velocity-driven colour is controlled by a relative velocity value between 0.00 - 1.00. This velocity "factor" is derived from the triggering MIDI event's velocity(*), as the relative distance between the MIDI velocity floor and ceiling defined in Core > Simulation and clamped to 0.00 - 1.00. Values below the floor become 0.00, values above the ceiling become 1.00.

This velocity factor is then adjusted by the Response curve variable. This value is the curve value used in graph variables, and so negative values weight the response curve towards lingering in the low range for longer and positive values weight the curve towards the upper range.

Finally, the curve-corrected velocity factor is used to sample a colour between the given colour slots. Colour slots are blended in H/S/V colour space, and so blending from red to blue will pass through pink.

Usage

This is likely uninteresting for computer-generated MIDI, but great for live-performed MIDI to visually show voicing or strong contrasts.

Be mindful of the relative luminosity of colours; using pure blue for the maximum velocity colour slot is unwise due to blue looking visually darker than any other colour, leading to visual confusion.

Gradient

Behaviour

This behaves similar to the above Velocity mode in that colour slots are used to create a H/S/V gradient, which is then sampled by a 0.00 - 1.00 factor. The factor for Gradient is derived from the note index (position from the left-most A0 key) divided by 88 (the number of keys). Colour slot labels show the nearest note to where that colour slot will be perfectly represented.

Usage

This is used to create a static colour for each element, but nicely gradient'd across the keyboard horizontally. Be aware that due to H/S/V colour space being used to create the colour gradient, blending between two "distant" colours (in hue-space) will result in showing a lot of colours in between the two given colours. This mode works best when using two similar colours, or going full-on rainbow and using red-green-blue-red to get a full spectrum.

Key series

Behaviour

This mode shows pure colour slots with no modification, starting with A0 showing slot 1 and then subsequent note indices showing the next colour slot. Once the available colour slots have been exhausted, colour wraps back around to slot 1.

As an example, given 4 colour slots, the bottom end of the keyboard will show the following slot colours:

Note index value: 1  2  3  4  5  6  7  8  9  10 11 12
Colour slot used: 1  2  3  4  1  2  3  4  1  2  3  4

Usage

By using 12 colour slots, each pitch can be granted a specific colour with Key series mode. This can be used to great educational benefit by matching semi-standardised classroom pitch colouring (as seen in this Classroom preset(*)), or to highlight a particular scale or note in a scale, or to highlight black keys from white keys. By using 88 colour slots, each individual note index has its own colour slot. This is reflected in slot labelling when using 12 or 88 colour slots.

Cycling

Behaviour

This mode changes colour over time, and moves forwards through each colour slot based on the given Colour change tempo (BPM) (beats-per-minute). At 120 BPM, colour will pass through 2 colour slots every second. Colour blending smoothly wraps around by moving through slots in sequence:

1 2 3 4 1 2 3 4 1 2 3 4 ...

Each new note event is given a random starting offset (shared between any elements spawned by the given event) within the colour slot blending, and blending once again occurs in the H/S/V colour space.

Usage

Due to picking a random start point, a speed of 0 BPM will allow Cycling mode to instead give random static colours between the specified colour slots.

Be cautious when using a higher speed with strongly coloured slots, as the luminosity difference between colours can make this visually uncomfortable.

Notes / sec.

Behaviour

Once again, this mode uses a factor modified by a Response curve similar to Velocity. Floor and ceiling to the factor are derived from Notes per second (min) and Notes per second (max) sliders local to this mode.

The source notes-per-second value is calculated by incrementing a tracker by 1 every time a note is played (on the given simulation channel(*)), waiting one second, and then decrementing that counter. This raw tracked notes-per-second value is then smoothed by Core > Simulation > Colour response > Blending sensitivity.

Colour is blended through slots using H/S/V space.

Usage

This is a relatively niche mode, best suited to pieces with a strong contrast in speed of notes delivered and representing that contrast automatically. Repeated chords tend to build notes-per-second disproportionately faster than expected. Min and max values often need to be calibrated to the specific piece of music for this mode to really shine.

Activity

Behaviour

This is identical to the Notes / sec. mode, but using the total simulated activity(*) rather than notes-per-second. Also uses Core > Simulation > Colour response > Blending sensitivity.

Usage

Another niche mode, but reflects the loudness contrasts of a piece which otherwise does not change note density better than Notes / sec. mode. Again, min and max values often need to be calibrated specific to a piece of music being played.

An alternate use for this mode is to set the Total activity (max) value to something barely above 0.00 on an element like a light bar. This allows an element to "activate" when performance begins; useful in a live setting where Keysight is running but otherwise not doing a lot.

Random

Behaviour

Colour is randomly assigned from slots every single frame.

Usage

This can be used to make flickering effects by having multiple slots of slight variation on the same colour (as seen in this Laser preset). It can also be used to give Particles a different random starting colour over time.

Useful tricks for editing colours

Copy/pasting colours

These icons can be used to copy (left) and paste (right) a specific colour:

And these ones typically found on a Colour menu tab can copy (left) and paste (right) an entire collection of colour settings:

Using these buttons can drastically reduce the editing time required in Advanced menu mode.(*)

Colour multiplication

There are many situations in Keysight where one colour is being multiplied by another colour, such as:

• A Pulse that uses an image texture and colour settings
• Coloured Note objects illuminated by Note lights
• Reflections(*) using a multiplication mode

In all these situations, the resulting colour on screen is determined by Colour 1 * Colour 2, which occurs in R/G/B space. Using an example of Orange(1.00, 0.50, 0.00) and Magenta(1.00, 0.00, 1.00):

         Colour 1   Colour 2     Resulting colour
Red        1.00   *   1.00    =        1.00
Green      0.50   *   0.00    =        0.00
Blue       0.00   *   1.00    =        0.00

This gives us Red(1.00, 0.00, 0.00), which may not be desirable, or intuitive. Multiplying primary colours in this way invariably results in Black(0.00, 0.00, 0.00).

Additionally, colour multiplication of the same colour twice is common due to Note objects getting illuminated by Note lights. Again with the example of Orange(1.00, 0.50, 0.00):

         Colour 1   Colour 1     Resulting colour
Red        1.00   *   1.00    =        1.00
Green      0.50   *   0.50    =        0.25
Blue       0.00   *   1.00    =        0.00

Despite using the exact same colour for both the Note object and Note light, we have a different colour appearing in the final render.

It is therefore wise to only have one aspect of an element using colour, and then any multiplying of that colour sticking to pure White(1.00, 1.00, 1.00). For example, here is a usecase:

"I want blue Notes, but illuminated in red."

Setting the Notes to Blue(0.00, 0.00, 1.00) and Note lights to Red(1.00, 0.00, 0.00) and not touching the Backdrop could be a plausible, intuitive attempt at implementing this... But it will fail due to Notes not being illuminated at all by the Note lights!

The correct method of implementing this usecase would be to make the Backdrop Red(1.00, 0.00, 0.00), the Notes Blue(0.00, 0.00, 1.00), and the Note lights White(1.00, 1.00, 1.00).

Centralising brightness

Many elements have both some form of base colour(*) and brightness(*). The final visual brightness is determined by multiplying both of these together, and so it is very easy to modify the Value of a colour downwards to adjust brightness rather than adjusting the actual brightness.

However, repeatedly editing the same element in this way often results in a situation where a 0.50 Value colour is then being multiplied by 2.00 elsewhere, resulting in a visual brightness of 1.00 despite this value not being seen anywhere. This makes presets(*) harder to edit later on!

It is recommended to try and keep any colours on elements that also have a brightness component at max Value on the colour picker, and use the brightness value as a master control for their visual brightness.

Primary colours and luminosity

The human eye is weird.➚ Different colours of exactly the same objective energy intensity will look differently bright to an observer, and this is very easily seen in an application like Keysight that allows cycling through fully saturated colours.

As a general rule, pure Red(1.00, 0.00, 0.00) is quite "dark", pure Blue(0.00, 0.00, 1.00) is incredibly "dark", but pure Green(0.00, 1.00, 0.00) is surprisingly "bright".

Be very cautious when using primary colours, especially Blue(0.00, 0.00, 1.00). Be doubly cautious when using the Cycling colour mode!

When desiring a blue colour, consider using some kind of sky-blue rather than pure Blue(0.00, 0.00, 1.00).