Preset pallets not included on all fixtures

[DaveH]

Hello,

I've come across a bit of a prob,em recently when patching my pearl expert. I'm running titan5.0.

When I patch several of the same fixtures often my preset pallets will only apply to the first of several fixtures patched. Today this happened with both my mac2ks as well as several LEDs. I had some smaller beam fixture where the palettes worked fine on every fixture.

When I select an entire range of fixtures and then choose a red pallete or a gobo pallete only the first of each type of fixture is affected.

I turned on the option to apply preset pallets in the patch menu. I tried patching the fixtures one at a time and also choosing my total number of fixtures from the patch menu. Either way I had the same problem with preset pallets only working on the first fixture in a line of similar fixtures.

I have experienced this problem several times in the past and typically the workaround is to start a whole new show and it works ok. This time I have a ton of time into creating a show and now I want to add several more lights into it.

I can create pallets just fine, but i feel like I'm spending a bunch of time on something that should be rather automatic. Perhaps the Align function could help since the data is there for one fixture.

Any help is appreciated.

Thanks

[icke_siegen]

Hi Dave

hm, really weird. Are you talking about pallettes on the real buttons, or in the windows (positions, colours, Gobos&Beams)?

I'd say at the moment your best bet is re-writing the pallettes using align, as you've already suggested. I'd try at least once to write a pallette for one fixture only, carefully observing that this is written as a 'Shared' pallette - this should be applicable to all fixtures of that type.

Another part would be to have a closer look at the issue. You might send the showfile, and the logs (-> Log collector) to software@avo... However, I'd be curious to have a look myself, albeit I of course do not possess the means to change the software myself. So, feel free to send the files to me as well.

S.

[niclights]

Unfortunately there is a bug in v5 where preset palettes for second fixture types store as normal and also any subsequent patches of these fixtures don't add to this (you can see this if you view the palettes). This is fixed in v6.

[CSmithDesign]

Hello,

What do you guys mean when you talk about recording palettes using "align?" I'd love to know as I've had a couple problem with palettes as well.

My problem goes like this: I'm making a position for all of my movers and I'm ready to record the palette, I record the palette on top of an old one (that hasn't been updated yet) and once I do, the lights snap away from the position into something like a combination of my previous palettes and that is how the new palette gets recorded! So, I have to re-do it all. This happens whether or not I click replace or merge on the palette (I've had a lot of shows to test this...). I have also had this same problem while recording other palettes

This problem is intermittent, but I've had some success in fighting it by ALWAYS recording palettes in the same way: "RECORD PALETTE X," I don't use the shortcut way of recording palettes.

Is this also a known bug that will be fixed in V6? Do you think using this align idea would also help?

Thanks

[niclights]

The align function is just a way of setting the value of a chosen attribute on selected fixture(s) to the same value from another fixture. You might do this before recording a palette but it is not a record palette function as such.

I am 99.9% sure that the problems you have been having are due to the software automatically defaulting to a shared palette because all the values in the programmer for the fixtures/attributes are the same. If you don't intervene and manually change it to normal before merging then all the values become shared breaking your palette.
A typical use case might be where you tilt all fixtures by the same amount and then created a fanned pan look. This automatically defaults to normal because the pan values are all different and all is fine. If you then decide you want to tilt them up a bit more but only adjust the tilt then the software sees just identical values and defaults to shared.
Technically this is not a bug although there could be an argument for a design change which prevents overwriting normal with shared. In the meantime always check everything before storing a palette (forgetting you've set a mask is a similar trip hazard). Other ways to avoid the issue might be nudging values back into the programmer or using Edit Palette which should both ensure the software sees it as normal automatically.

Also remember that there is an undo function. If you notice this mistake immediately (or at least reasonably soon) after then just undo to before you recorded the palette.

[CSmithDesign]

Thanks Nic,

I realize I may not be as clear on palettes as I thought. How do you set whether or not it's a "shared palette" or not and how do you set the palette mask? Can you set different masks for different palette pools?

Thanks,

Chris

[niclights]

You can toggle shared/normal and set mask using the appropriate softkeys in the record palette menu.

I don't know what you mean by palette pools. The mask just filters out what will be recorded (in combination with record mode).

[CSmithDesign]

By palette pools I mean which window (ie the positions window vs. the colors window), can you set a different mask for each one? I find myself sometimes accidentally recording intensities or gobos into my positions and so forth.

[niclights]

They are designed so that if you use quick record (click on an empty handle) then they do automatically mask to the relevant group. Other record methods deliberately don't mask so that you are not limited in what can be stored in any given palette window.

So, either use quick record or manually set a mask. Personally I find the most adjusted palettes are positions and so tend to leave the mask set to position.