Smart color palette use

[Joost Schevers]

Hi Mathieu.

I'm a fan of the "color palette" function.
I've got a Novation Launchpad Pro and created a project that allows me to select fixture groups and then choose an effect for that fixture group.

When I have created a nice effect on a grid with a certain palette, I currently duplicate the grid and then change the palette on the fixture attributes on the grids.

So for every effect, I have as much duplicate grids as I have different palettes.
This is quite a bit of work to set up and makes the project quite large (and it takes quite some loading time).

This is what I am trying to create:
1) Have a way of selecting one of the color palettes to use on all fixtures

2) Select a color effect that determines which fixtures get which color within that color palette

3) Select a vdimmer effect that determines which fixtures light up and which don'

This way, I can have a certain combination of vdimmer effect and color effect to quickly switch to a different palette (let's say from a "red to blue" gradient, to a "pink to green" gradient).

Or, I can have the same palette, but have a different vdimmer brightness effect (let's say from all lights blinking on and off at the same time with a certain interval, to a chase from left to right where only one light is lit at the same time).

Or, I can have the same palette and same effect, but have a different color effect (let's say instead of all lights fading from red to blue in sync, to having half of the lights turn from red to blue and the other half inverted turning from blue to red).

So in other words, my aim is to be able to control the vdimmer effect separately from the color effect (which fixtures get which color from the color palette) separately from the palette being used.

The vdimmer functionality you added quite some time ago solved that specific part of my problem. (I've been "wanting" to achieve this goal even since before that time).

My problem is that in order to select a different palette, I have to duplicate a grid and select a different palette for that grid.

And then I have to somehow get that grid to get "power".

So X different palettes times Y different color effects in order to get all the different combinations.

I've been experimenting trying to resolve this in such a way that I can have X palette grids and Y color effect grids and only need to have X+Y grids.

I could not get the end result I need, but I have an idea that might be realisable and worthwhile for you to consider for implementation.

I have a sample proof-of-concept project, attached to this post, where I have create 3 groups.

If you look at the color-effect group, you will notice that I've create 3 simple color-effects grid.
I've also set up the media server with to use these 3 different grids as a background.

For one of the color palette grids, I have set the background to media 3.

The vdimmer-group has a simple sequencer that sequences over 3 different vdimmer-effects.

So at the moment, the output is alternating between these 3 different vdimmer-effects, using the activated color palette, based on the selected background color-effect grid.

So my idea:
I would like to be able to set the color-effect group as a background in the media server.
So that the background of the palette grid is sourced from the currently activated grid in the color-effect group.

The project contains a color-effect sequencer that is alternating between the color-effect grids within that group, so if only that palette-grid background could source from that group instead of a particular effect.

This is quite a long post, as I'm trying to explain in the best way possible what I'm trying to achieve and how I think I got close.

I realize there are other ways of achieving less complex projects with different color-effects without using palettes, but I'm really hoping to be able to use the palette function, as it makes it so incredible easy to select different combinations of colors.

I can also imagine there are other ways of achieving my goal, but I haven't been able to think of anything that doesn't involve duplicating every color-effect for every palette I'm adding (X*Y).

For example: being able to select which background from the media server would be used for a grid using a formula.

I'm just trying to get to a point where I can define X color effect, Y palette groups and Z vdimmer effects (so X+Y+Z) and be able to use every possible combination of X, Y and Z.

I hope I have explained my "problem" well enough for you to either point me in the right direction on how I can currently already achieve my goal, or for you to think of some feasible additional feature implementation for LightJams that would help me out.

I've read quite a few posts and have seen references to using grid precedence and relative hue attributes, but I don't think that will solve my problem in the way I'm hoping it would, as I really want to use the palette feature to pick the colors to be used.

Looking forward to your thoughts and reply very much,

kind regards,

Joost. 

[Mathieu]

Hi,

A new function has been added to select the background of a grid using:

grid.background(mediaId, componentId): Set the grid background to the specified media (1 is the 1st media) and component (1: hues, 2: saturations, 3: intensities).

https://www.lightjams.com/history.html

Let me know if it does what you need.

[Mathieu]

I've done a quick test with the grid.background function. Here's the modified project file with the 3 sequencers fully active. The color sequencer puts the effect number in a global memory and then the active grid in the palette group uses this value to set the background.

So the color sequencer does:

xtopercent(gmem(0,counter(0,grid.lastx,pulse(3))))

And a dummy source in each grid under the palette group does:

grid.background(grecall(0)+1,3)

[Joost Schevers]

Hi Mathiue.

I had replied almost instantly to your message, but looking back because I have some additional follow-up feedback I notice my reply is not there.
Don't know what went wrong, my apologies.

So first off: thank you for your response.

What you showed me indeed did the trick for me.
I have succesfully experimented with it and now have a sample project for myself which is 15 times smaller (at 1.5 MB) than my original project (at 30MB).
In the original project I had to copy the attributes and effects for each color palette resulting in big number of grids, project size and the corresponding long loading time for the project.
This solution is much more scalable.

Since having succesfully achieved this I have been experimenting a little further, especially with the function grid.colorGradient.hue(x, y, percent).
Reason for this is I would prefer not to have to create a separate grid for each color palette I want to use, further reducing the number of grids and the number of attributes with a certain palette configured on it.

It seemed the grid.colorGradient.hue(x, y, percent) function would allow me to achieve this.

And I did achieve it.
Right now I have a sample project that demonstrates how I only have to add a single attribute with a certain color palette configured in order to drive a 20x20 grid with an effect mapped to the color palette.
Adding the use of a new color palette as such only required adding a single additional attribute with that certain color palette configured on the same grid.

Have a look at the sample project I'm attaching.
The magic happens on the grid called "main-with-project-notes-color-palette-mapping".
There are only 6 attributes in the project that have a palette configured to them, one for each of the color gradients I put in the project.
I have added project notes with an explanation, as I think this project might be usefull for others as well, should you not be able to implement my suggested features for some reason (e.g. performance concerns or something).

But, it still feels a bit unnecessary to have to go through these "dummy" attributes in order to get to the color gradient, so I have a suggestion that seems likes it is not to hard to implement:

I would like to see a generic function like this, so there is no need for attributes on the grid with a configured palette: instead of going through an attribute, select a color gradient from the palette list using an indexPercent

palette.colorGradient.hue(paletteIndexPercent, valuePercent) - Get the hue of the color gradient selected by paletteIndexPercent at the percent value
paletteIndexPercent: will select the corresponding color palette from the list of available color palettes based on this percent value. For example, 0% is the first color palette in the list and 100% is the last one.
valuePercent: determines the position within the selected color palette of which the hue value is retrieved

If that's not possible, another way of getting a bit more programmatic flexibility would be this: adding a function to change the selected color palette for an attribute at the grid, similar to how the selected grid background can be modified to grid.background(...):

grid.setPaletteAt(x,y, paletteIndexPercent)

If it is possible to implement my suggestions, this could further simplify the project required to achieve my goal.

Keep up the great work!
Love LightJams and it keeps getting better!

[Joost Schevers]

PS: I only implemented the "colorGradient.hue" bit.
In order for the last pastel colors gradient in the project to work properly one would ofcourse have to do similar stuff for saturation/intensity, but the goal of the project was to show the feasability.

[Mathieu]

Hi,

Thanks for sharing the result of your experimentations! It certainly will help others. 

About the need to have an attribute on the grid linked to the color palette entry, it's because the color palette entries aren't identified by slot numbers like the media library. Without that, there's no way to tell which one you want from a formula. Using the order as seen in the color palette window would be too brittle as it's an alphabetical order and renaming the entries might change the order.

I'll continue thinking about it.

[Joost Schevers]

I understand.

My suggestion: add an adjustable (optional?) order number for each palette.

Instead of indexPercent you could also opt for indexOrderRaw, thereby specifically identifying the palette with that assigned number.

I’m positive you will think of an elegant solution, like so often.

Kind regards,

Joost

Op 27 nov 2024 om 14:27 heeft Mathieu <mat...@lightjams.com> het volgende geschreven:

Hi,

--
You received this message because you are subscribed to a topic in the Google Groups "Lightjams" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lightjams/5KmRPSxFtm4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lightjams+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lightjams/d1c99a56-bcb0-4b3d-b10a-4cf4736e55d0n%40googlegroups.com.

[Joost Schevers]

Just for future reference for others who may be interested in working with palettes, here's is an updated version with these modifications:

* Attributes are now at the exact location matching with the background power
* Saturation and intensity are now also calculated from the color gradient

So this fixes the problem with the colors of the last gradient not showing up correctly as pastel colors.
And having the attributes at the location of the background power makes the grids smaller.
In the previous project the attributes were impacted by both the calculated power as well as the background power, causing colors to skew (and outside the color gradient palette too).
But the easy fix for this was to subtract that background power from the calculated power.

Feel free to share this project if you like.