Chamsys: Updating pallets through macros

[Manuel1975]

Hi There,

 

Im looking for a way to speed up my pallet editing. Right now I'm doing the following:

 

Macro which updates a color bump:

 

(this part updates first color of col bump)

-Key press " Blind button"

-Key press "Group Button"

-Key press "1" (select group 1)

-Key press "color Button"

-Key press "1" (select color 1)

-Key press "Record button"

-Key press "Color button"

-Key press "101"

-Key press "Enter button"

-Key "y" (to confirm record over an other pallet)

(this part updates second color of col bump)

-Key press "2" (select color 2)

-Key press "Record button"

-Key press "Color button"

-Key press "102"

-Key press "Enter button"

-Key press "y" (to confirm record over an other pallet)

-Key press "Clear Button"

-Key press " Blind button"

 

---End macro---

 

This takes about 2-3 seconds. Thats very slow. On a code level this could be executed in a nano second...

 

Do you guys know of a way to update your pallets faster?

 

Cheers,

 

Manuel

[Wol]

could be executed in a nano second...

 

I don't think you appreciate how small a nanosecond actually is in terms of computing... ;-)

 

Please see the reply we gave on the bugtracker last week regarding this issue.

[Manuel1975]

Please see the reply we gave on the bugtracker last week regarding this issue.

 

Sadly the reply was something like:

 

Status: resolved

Resolution: won't fix

 

So now I'm trying to get user input on how to speed up my work... Or are you guys thinking of a way to speeding up the process...!!??

[Wol]

Can you try clarifying how you're using these two macros as I don't think I've ever come across another user who wants to update palettes from a macro like you are. This is something which is usually done once when changing venue and using different positions / colours, rather than something which should be regularly performed throughout programming.

 

Can you give a bit of context as to how you use the two macros you mention above?

[Manuel1975]

Can you try clarifying how you're using these two macros as I don't think I've ever come across another user who wants to update palettes from a macro like you are. This is something which is usually done once when changing venue and using different positions / colours, rather than something which should be regularly performed throughout programming.

 

Can you give a bit of context as to how you use the two macros you mention above?

 

The macro I describe above is 1 macro and it updates 2 steps of a color bump.

 

Context:

I programed a variety of chases and FX in a large number of patters. Now I want to "fill" these patterns with pallets and have them do a color and/or dimmer bumps (or what ever other parameter) . To achieve this I have combined color and dimmer pallets in the color pallet window. For instance: by changing the two pallets (each make up one step of the chase or FX) to bleu and setting the dimmer info of pallet 2 (chase or FX, step 2) to off I get a dim chase in bleu. By setting the dimmer of both pallets / steps to full and changing the color of pallet 1 / step 1 to white I can reuse the same chase or FX pattern as a color bump.

 

Why does it need to work fast:

At the beginning of each song I update the contents of these pallets and thus definine my look for the song. At this moment it takes 2 to 3 bars, thats 12 full counts (at 120 bpm) to update all the pallets for al the different fixture types. I could of course update before the song starts but the band I work for does sets in which one song evolves into a other. So I cant update each song while there is no music playing AND I love the creative freedom of for instance changing to a dimmer bump in a climax and in a breakdown to a color bump...

 

////////////////////---->

 

One thing which would theoretically speed up the process is having a macro only moving pallets around in the color pallet window.

 

For this to work the handling of the "pallet link" in memories should work in the same way as pallet FX. A pallet FX refers to a pallet number. This is very different form a cue <-> pallet link. A Cue stays linked to the same pallet even when the pallets position is changed.

[gyro_gearloose]

I can't quite visualise what you are trying to do, but it sounds like you are trying to make the software adapt to how you want to work rather than adapting yourself to the way in which the software actually works. This is a common trap to fall into, particularly when moving from one make of lighting desk to another ( For instance, I have seen someone try and make an ADB Vision 10 behave like a Sirius 24. You know who you are :) )

 

If I understand you correctly, you seem to want to alter one attribute of your fixtures in a chase? Can't you just put a dimmer chase on playback 1 for example, and a stack of colours on playback 2? This will allow you to select your colour and then run the chase. You could even have a colour chase on playback 3 and run that with playback 1 to get a dimmer/colour chase.

[Manuel1975]

I could off course program a chase in a certain pattern which does a color bump combination AB,

 

and program the same chase pattern for color bump combination AC,

and program the same chase pattern for color bump combination AD,

and program the same chase pattern for color bump combination AE,

and program the same chase pattern for color bump combination AF,

and program the same chase pattern for color bump combination AG,

and program the same chase pattern for color bump combination AH,

and program the same chase pattern for color bump combination AI,

and program the same chase pattern for color bump combination AJ.

 

OK, Now on to all the other color combination possibilities. Well, that was chase pattern nr 1. Now on to chase pattern 2....

 

You get the point right?

 

I know I will never ever program ALL the possibilities but to be able to update the contents of a Chase, FX or Cue is a über cool feature. AND allows for greater creative freedom. NB, IF this works for dimmers and colors it can work for all parameters and one could very easily stack parameters and thus create very intricate looks....

[paulears]

I'm afraid I don't get the point at all. Sure you could work this way, but I'd get myself mega confused. Just working out a way to access and identify these combinations would seriously confuse me. What would you have a huge excel spreadsheet to try to itemise them all? You cannot really want to work this way? Wanting access to every permutation is a lofty aim, but surely unworkable like this?

[niclights]

I understand the requirement. It is something I have been asked for many times but is not easy to find a solution, or at least one that is intuitive.

 

Instead of just busking a single colour using palettes here we want to busk a chase. I don't think the solution is macros that reprogam.

Ideally you want some sort of 'virtual' palettes. When you make the chase it would be built using these (ie. cue 1 - virtual palette 1, cue 2 - virtual palette 2). Then you need a UI way of applying a standard palette to the virtual one. This would be the crucial difference between the two types of palette but it is not obvious how to go about this from an interface point-of-view in a way that is fast (ie. few button presses) but also retains the ability to actually apply them, either live or when programming.

[indyld]

I'm not convinced that the "all of the colours, in all of the sizes" approach to preparing even a busked show is the way to great lighting, or that things being cool to pull off in programming actually improves audience experience. However, new approaches to control and flexibility are always interesting and often result in new ways of achieving new effects etc.

 

I don't think keystroke macros are the answer and if I were to require this level of on the fly granularity, I'd be looking to use grids and specific media in layers with colour mixing kit, but realise that doesn't help those stuck with fixed wheels. One thing that might be good to add to the functionality of grids is FX driven x,y control of fixture positioning on the grid, similar to how something like LightJams affords possibilities by moving the control channel relationally around that which sets the values.

 

Right now, the answer isn't leaping out at me, possibly because of a slight feeling of "if I were going there, I wouldn't start from here" kinda thing. I think Nic is right. How to make this adjustment any more intuitive and quicker than it is with standard palettes; even layers of nested ones.

 

edit to add a thought: every time I wonder if something can be done on a console, it used to be that the GrandMA had some way of doing it. I'm not so familiar with the MA2 but would be interested to hear the thoughts of the MA programmers here.

[tom_the_LD]

edit to add a thought: every time I wonder if something can be done on a console, it used to be that the GrandMA had some way of doing it. I'm not so familiar with the MA2 but would be interested to hear the thoughts of the MA programmers here.

If I've got the preface of the thread right, which is essentially a colour bump which the macro then changes the colours it bumps between, then you could do this on an MA2 using an absolute effect with high/low values referencing the palettes.

 

When you create an effect on say a colour attribute, you can then specify the two values it goes between - so a high of the colour palette dark red for example and a low of the colour palette dark blue. You could then simply change this by editing the effect and selecting different colours for the effect to go between. I'm sure you could also write a macro which asks you which colours you want to go between, for which you could type the colours and it would update the effect.

 

Or you could just have a single cue, with the button assigned to be a temp, which bumps to a colour of your choice - upon the release it will then drop back to whatever colour the lights are held in from a playback for the off time specified. To change the colour of the bump you could easily hop into full blind (blind edit), or even partial blind providing there's nothing in your programmer, select a new colour and store merge or store overwrite depending on the effect you're after.

 

Has that made any sense at all?!

[Joe Bleasdale]

I can't help but feel that this macro business is going a little too far to be honest.

 

I think the overall solution here is - become a better, faster programmer. As Rob said, you don't need to create every possible colour effect for a busking show to be good. You just have to know how to busk, and if you want some bonus points, research the music of the bands that will be performing. Or at the very least practice busking to the same type of music.

 

I don't program any Chamsys desks, but the logic is the same across the board. Effects are as simple or as complex as you want them to be, whether you are using a waveform based effects engine, or an engine that supports absolute step values like Eos or MA2, or even chases with some well thought out timings in them. I once sat down with probably one of the best programmers on this forum (he knows who he is) and it took all but one question and 5 minutes in front of a desk for him to completely change how I now think about complex effects.

 

If this was me, on my desk and the LD had asked for a busk page capable of what you are asking, I would do this...

 

Fader 1 - Base Values. Colour A, B, C, D etc

Fader 2 - Additive Effects with no base values so they just go "over the top" of the values on fader 1

Fader 3 - CMY or Colour wheel effects speed master. The fader simply controls the speed of the colour effects for the fixtures in fader 2.

 

The method Tom mentioned with bump buttons is also a really good way of doing this, if you can be bothered to sit hitting flash buttons - I doubt that considering you want a macro to do all your work for you ;)

 

Thanks.

[niclights]

I don't think there is going to be much difference in updating the values of an effect compared to updating the palettes used in two steps of a chase. And you will face the same problem if you try to write a macro as the software will just replicate keypresses, rather than simplifying the process and therefore be too slow (for this application). If macros simplified then it would probably work but then what happens when you really did want the exact key presses and not what the software decided you wanted?

 

Colour bumps, aside from the obvious flaw of having to keep pressing, still have the main issue of needing one bump for every colour you might want to bump to.

 

This requirement is a very similar to the problems faced before we had virtual dimmers. When working with LED's that had no dimmer channel you would have to decide what colour chase(s) you might want and record them in advance. This is very restrictive in rock'n'roll (or club) busking, particularly when trying to maximise playback real-estate and minimise page changing which can be too slow or confusing. Since virtual dimmers came along we can now happily record a single dimmer chase and select our colour palette.

Colour bump chases can be a nice tool to have available but need a similar solution. It's not about using every available combination but simply not knowing the one and only combination you might need during the performance. The reality of in-house busking (which covers the majority of small-mid level touring acts) is you won't have time to research or program. Other than a general idea of genre you won't know until the song starts playing...

[Manuel1975]

Guys,

 

Thank you all for your feedback.

 

I don't want to be rude but the topic of my post was not IF I should or should NOT update my pallets through macros and so on...

 

I want my macro to execute its task FASTER. That's why I documented al steps of the macro in my first post so you could see what I do. I have programmed the macro just as I would update the pallets manually but maybe there are some tricks which would enable skipping some programming steps and thus speed the macro up...

 

//////////////

 

One idea I had is the following:

 

Having a macro only moving pallets around in the color pallet window could be the way to go...

 

But for this to work the handling of the Chamsys "pallet link" in memories should work in the same way as pallet FX. A pallet FX refers to a pallet number. This is very different form a cue <-> pallet link. A Cue stays linked to the same pallet even when the pallets position and thus pallet number is changed.

 

///////////////

 

Anywayzzz, it's this out if the box way of thinking I was hoping you could guys could help me with. As I sayd earlier there might be some programming tricks which you use on Chamsys or an other brand desk which could speed up this task dramatically...

 

Hope you can help!

[indyld]

But for this to work the handling of the Chamsys "pallet link" in memories should work in the same way as pallet FX. A pallet FX refers to a pallet number. This is very different form a cue <-> pallet link. A Cue stays linked to the same pallet even when the pallets position and thus pallet number is changed.

 

So create a custom FX that sets a specific static colour for your fixture type, if you are dead set on using your FX shifting macro method.

 

It seems that you had your answer from the software developers regarding the speed of the keypress macros both on the Cham Sys bug tracker and here. Why would users be able to circumvent the software as it is designed?

 

Your answers here are from experienced console programmers and I'm sure if Grum was around/had anything to add, he would pitch in too. There is thinking out of the box (which many console users and designers do on a regular basis in order to achieve new things) and there is hoping for a different answer than the one you get. Quite a number of questions on the Blue Room result in a discussion about the merits of a particular technique or alternatives otherwise the answer to many questions ends up being things like "No", "32 including the console" and "Lee 165".

 

This is why context and intended usage is important because it opens out the discussion, possibly to a solution that the OP hasn't considered. :)