Azure column playback tips...

[Wol]

I might be using an azure 2k to be running a small showcase show soon, which will have a getin, performance and getout within about an 8 hour period ( hopefully getting some preplotting time a few days before!)

Im planning on busking it and keeping track of which playbacks are needed for each act, but ive never used an azure before and unfortunately dont have a simulator for it.

the show will hopefully have 12 martin procolor 400s, 8 martin 250s, 4 roboscans and a few atomics ( and maybe some generics patched in too). Do people have any good guidelines on the layout of things within the playback section to help with busking. After reading the "only one item in a column can be played back at once" just screams " youre going to get stuck" to me!

for example, do you have a playback page per group of fixtures, then use each column for each attribute( e.g. one for pan/tilt, one for colour, one for gobo).

any help that previous users of the azure can give would be greatly appreciated!

[light-o-matic]

Hopefully I'm not too late to help.

1) Each fader is an independent playback, only the 4 buttons in each column share a playback.

2) You don't have to worry about the column situation for simple LTP memories, eg color change, gobo change.. because once they are played back, they will stay where they are, you can use the same playback to play other things. So color change for one fixture and gobo change for another can go into the same column, no problem.

3) If you store things that will STOP if you take away the playback, that is: chases, shapes, or dimmer.. then you DO have to worry about the columns.
Therefore if you store those things on buttons, you have to either dedicate the column to that fixture group or make sure you don't need more than one thing in that column at the same time.

4) You probably don't want to put each group of fixtures on different pages. The reason is, even though they are different pages, they are the same playbacks. So if you have a chase/shape/dimmer for one fixture group in the first column page A, and a chase for another fixture group in the first column page B.. you cannot use them at the same time. Again simple LTP changes eg color change etc is no problem. But I think if you need to use multiple pages, it is better to decide what columns you are going to use for specific purposes, put your most important stuff for all fixture on the first page. Then overflow into that same layout on additional pages as you need to.

I busk it all the time (mainly I do party lighting now). The way I lay out my Azure is:

Dimmers ONLY for each group/subgroup of fixtures are recorded on faders toward the righthand side of the board. If I'm using strobes I put the dimmer channel for that all the way to the left. Then I will have some faders in between with pan/tilt shapes I can superimpose on whatever I've got going.. and dimmer pulse shapes. If I have LED fixtures I might have a color shape for those on a fader. I have the playback attributes set for shape speed or size set to be controlled by the fader.

For the buttons, I will usually have at least one "safe" playback for each fixture group, that is, someplace I can go that looks good to get me out of a jam when things get too unruly. Usually I put those in a column together all the way to the right, so I can just walk down that column to get my "default" look on everything. Keeping in mind these playbacks set everything BUT dimmer, so I can still control those on the fader. Or, sometimes I will put these across the bottom row of buttons, with each "safe" playback directly above the fader dimming those fixtures. So if I play each one of these, then bring up dimmers it will look ok!

Then I will have some buttons for positions, some for colors, some for gobos. I will keep them organized by fixture group. These are mostly LTP changes so I don't have to worry about the column situation. I don't try to put every gobo, every color, every effect that I want to use into its own playback because there are just not enough buttons for that. I program a set of buttons with all the important positions, a set with color combinations, and some with gobos and effects. I try for my own sanity to keep it organized but since these are all LTP it doesn't matter. If I have shape or chase playbacks I have to put on buttons then I have to reserve a column for that, hopefully I can manage with just one or two columns of those! And I will push those all the way to one side. So if I am programming during the show (almost always) then there is no question where things should go.

But what I do a lot of is, instead of putting everything on memories I play stuff back using the palettes. So for example you don't need to put basic color changes all in memories, so long as you have the palettes programmed right, you can play the colors right from the palette. The only difficulty is that since those 20 buttons are shared, you have to make sure you are in the right mode, on the right page etc. But it is not that hard. You can also record palette entries on a blank palette page, with any attributes you want.. just like any memory. You don't have to just change one attribute with a palette. So you can program color combinations etc, using the palette as extra memories.

If you have a tablet you're better off. I don't have one. I want one but I can't justify the cost. If I can ever get one cheap it will be a happy day.

So in short.. my basic page "A" layout:

Faders: dimmers to right.. strobe dimmers, if any all the way left.. and shape (color/dimmer pulse/motion) playbacks or position playbacks that need to be on a fader go in the middle.

Buttons: "safe" looks for each fixture group, and most complex (multi-attribute) memories go to the right, above the dimmers.
Memories containing chases, shapes, or dimmer go all the way to the left, organized into columns.
Basic memories (favorite color combinations, gobos, and positions) go in the middle. I try to keep them organized by fixture group but it rarely works out.

Everything else usually ends up getting played back from the programmer/palettes.

If I HAVE to, then I overflow to other pages.

I got sick of entering legends. I still do it but I started doing it on paper, its easier when you're programming fast.

In short.. if you can plug in some fixtures ahead of time and make sure your palettes are set up right, they will make it much easier. Then record your favorite color combinations, gobo combinations and effects all together on an extra palette page.. voila you just got yourself 20 extra memories without having to use another page. And you don't have to flip palette pages as much.

What I really wish this board did is.. dynamically assign playbacks. That is, you have 20 playbacks that the board has enough processor/memory to manage at one time. But these are only needed for certain types of memories at certain times. If a memory contains only LTP attributes, then it only needs the playback to do the fade, then it's done forever. And often those fades are 0 seconds... So, button memories.. when pressed: Turn the light on, do the fade, if there is still something active (dimmer/chase/shape/other-LTP-attribute) then stay on. Otherwise, turn off and free the playback for another button or fader to use, ANY other button or fader on ANY page. Same thing with fader handle memories.. when the fader is at 0, free the playback for any other fader handle, not just the corresponding handle on another page. So you get 20 playbacks simultaneously active, on any page.. no positional dependence to worry about.

If it worked like that, I would use every page.. I would be so organized!
I think people would love it.

But I know.. the Azure.. they probably won't make anymore software changes for it. If they do, it will be Azure 2008 or whatever, it will run Windows There won't be anymore changes for the Boris motherboard.

But I won't upgrade for a very very long time. I can't justify the money, I can still do good stuff with the Azure I have. But maybe one day, after the Azure 2000 and old Pearl is old news and they don't care anymore, I can convince Avo to give me the source code so I can fix and change things myself...