Original LXSeries Forum

Hi there,

might be a total newb question, but I am planning to use LXConsole in two shows coming up, and want to teach myself best practice to save time...

re: Groups:

In the help it says:

Setting the level of a group proportionately sets the level of its marked channels in the current preset. Groups can be used to edit in live mode or any preset mode. Groups can also be included in cues by reference. When a group is included in a cue, its marked levels are automatically set into that cue. This makes it possible to change one group an have a number of cues that reference it also be updated.

I have done the following:

Setting up a group with 1@F and 3@50:

Live
1f
3@50
record group 1
1&3z
'
unmark

Recording a cue with group 1@F:

In Live:
group 1f
record 1


Recording a cue with group 1@50:

(still)In Live:
group 1@50
record 2

Here is the scenario, I want to now change the contents of group 1, to then automatically affect all cues that reference group 1, i.e. setting channel 1 in group 1 to 90% as opposed to full should then filter filter into cue one as 1@90 and in cue two as 1@45.

A) is this assumption correct? I have tried to just change the level in the groups tab, and it did not filter through.
B) Is there an option to include groups by reference into a cue (like I have tried) through command line? Or do you have to be in blind (the cue tab) to add the reference in the info>advanced window? If so, can you add a percentage to the use of the group (currently, it seems like you can only add the group number into it, so the group will always be used as @Full)
C) can I adjust the groups while in live and simply record over the existing group, with all references to it from cues staying intact?

Thanks, I just try to avoid learning wrong habits .

If you use a group to set the levels of some channels in Live mode and record a cue, those levels (and not a reference to the group) are saved with the cue. In this use of a group, it merely serves as a way to set the level of a number of channels at a single time.

Using a group as a "preset" is done in the advanced tab while in cue mode. When a group is used as a preset, marked channels in the group are set into the cue when it is updated. In this case, changing the group will also change all cues that include the group as a preset.

Importantly, when you use a group as a means of setting levels of a number of channels at once, channels that have a non-zero value are proportionately set to the level of the group. In the case of using a group as a preset, marked channels in the group overwrite any values stored in the cue when it is updated. In this case, if a channel is marked and set at zero in a group used as a preset, it will be set to zero in the cue.

Using a group to set the level of associated channels can be done proportionately. Using a group as a preset is direct and not proportionate to a level. (That's an interesting idea for a future version, however).

Cues that have groups included as presets are updated before they are played and when you view them in "Cues" mode. Recording over a group used as a preset will eventually change the levels in all the cues that reference it. You can force this update by selecting Cue=>Update All Cues. Or, if you make an unintended change to a group used as a preset, perhaps by marking unintended channels, you have a chance to correct the error before it overwrites a number of cues by going into "Groups" mode and editing it.

Yes, that would be an interesting feature! I am thinking along the lines of a touring show; say the Light's intensities work a little different to your previous set up, you can just adjust the level of channels in a group, which then proportionally affects all cues where this has been referenced. or going further, if instruments are exchanged between venues, you could easily tweak the look by changing the group in general, but then still have the flexibility of a level per cue.

maybe something as easy as in the advanced cue tab column for group the ability to input i.e. "1@50" as opposed to just "1" - determining that the cue references group 1 at a level of 50, as opposed to full...

another sexy way of doing things straight from life would be some sort of "reference" parameter - i.e. if you want to store a group reference (with or without) a relative level in a cue, the syntax could be something like:

(in live):
group 1 <referencial store shortcut>

or

group 1 @ 50 <referencial store shortcut>

which could then result in this being put into the advanced tab group section...

I am dreaming ...

The latest build of LXConsole, 3.1.4 (65C14) allows you to set a proportional level of a group included in a cue. This is done in the advanced tab of the drawer by entering the groupNumber@theLevel. An included group without a level specified continues to be included at 100% as before.

Changes made to included groups in the drawer's advanced tab do not update the cue immediately. The changes will set levels in the cue when it is next updated. This can now be done explicitly using a new "Update" button.

Groups can be included in a cue from the command line. To do this, press capital 'G' instead of lower-case 'g'. Shift-G will expand to "Group:". Lower-case g continues to expand to "group:" and works the same as before.

Including a group in a cue from the command line (as opposed to in the advanced tab) causes the cue to be updated immediately.

When including a group in Live mode, the group is included in the current cue. This may not be immediately obvious as to which cue this is. So, confirmation is required. If you are creating a cue in live mode, it is probably best to use the group in the normal way. Once you have the look you want, record the cue. Then, include the group.

Command line examples:

"Group: 1<enter>" causes group 1 to be included in the current cue.

"Group: 2@50" causes group 2 to be included in the current cue at 50%.

If you scroll a group into a cue the regular way by entering "group: n" and then scrolling while the cursor is over the main display area, you can set the group to be included at the current level by returning to the command line and adding '^' <enter>. Using the capital G version of the group command, "Group nn" and scrolling will include group nn in the cue when you press <enter> in the command line.

Including groups was originally intended for parameters of automated fixtures, such as the location of a moving light. By including the location of a mover using a group, if the placement changed, all you would need to do is to update the values in the group to change all the cues that included the location.

This is a powerful feature. But it comes with a price. You have to be aware of the fact that you have groups included in a cue. Because the included group(s) override the levels for their marked channels, you cannot make changes to those channels by re-recording the cue. Well, you can, but when you play the cue, it will update and the levels from the included group(s) will be restored.

Claude, you are a genius!

What this board is missing, is like buttons !!

Thanks heaps, this will help immensely. From the logic though, would it make more sense to have manual values being the highest in the hierarchy?

As in, cycles of iteration -

A) you apply your general look as a base, but
B) you adjust manually what needs to be adjusted with captured channels?

Of course, I don't know how well this would work with other people's workflows, but it seems to be behavior of other consoles.

Either way, it looks like there is a question lurking - how do we know to distinguish that there are values sleeping "underneath" a value? how do we know what is applied?

One solution that I have seen in practical application works like this:

A) if a manual value is applied (or a group has been used, as opposed to a Group), we see the value as before - i.e. numerical
B) if a Group is applied, instead of the numerical value, we might see "Gnn" underneath the channel in question (but still following the usual colour code of tracking, higher, lower, and manual (although if I understand it, that wouldn't come into play because the addition of the Group in live includes the update).
C) a sort of modifier key, or toggle key switching between this view ("Gnn" under a channel) and displaying the actual applied value (coming from the Group in question)

One functionality would be then a handy thing in this Layers-per-channel (including Group and manual values, whichever one is favoured): a per-channel stored "release" or "revert to background layer value key"...

i.e. in a scenario where the higher in the Group is applied with higher priority, this flag on a channel could make the value coming from a Group be ignored, and revert to the manual level below, which is recorded in the cue.

However, if the hierarchy works in the opposite way (which is what I would suggest), then this might not have to be a flag as such, but a sort of "NULL" value, i.e. channel 1@Null, causing a previously stored/applied manual level to be deleted (and thus revert to the value coming from the Group). Maybe, this already exists? I am still a little unsure about what the exact effects of marking/unmarking channels and/or @home could signify in this scenario.

As I said, just my tuppence worth, don't know if this would be easy or potentially changing things for people who like it/ have gotten used to the way it is/was before; But I thought, better speak up now than later (when people have gotten used to this recent addition/change ).

Bonjour Claude,


just checking in -

any thoughts on the optional hierarchy altering on a per-channel (or per-property) base? And/or the visual representation of values that are applied through Group Cues in the channel table? No pressure at all, I just wanted to prep myself either way for a plotting session next Tuesday, so that I know what to focus my usage of Groups on, if that makes sense.

It seems that display indication of channels that are being set by an included group(s) is a good idea.

I'm not sold on making any kind of hidden hierarchy of levels. I'm not really sure what you would use it for. The way a group functions as a means to setting the levels of a collection of channels is pretty standard. The "group" keyword is part of the ASCII standard that is used by LXConsole.

Including a group in a cue really does the same thing. It is an extension of the basic way a group operates. The only difference is that including a group updates automatically. So, when you change a group, instead of visiting every cue in which you used the group and re-recording after adjusting for the change, the application does it automatically. Another way of looking at it is that for every included group, the application does a "group: n@level" on the command line when it updates the cue. The result is like selective tracking but is based on the well understood behavior of groups in general.

The possible reason for an if-then-else hidden hierarchy seems to be solvable by using smaller groups of channels in varying combinations in different cues. The order of the included groups matters. If a channel is set by one group, it will be reset if it is marked in another group further down the list. So already you have layered control of channels.

Thanks Claude,

Completely understand, and wasn't aware of that hidden feature of a hierarchy of Groups !

Once again, thank you, and fabulous work on it all (OT, just getting my head around LXSeries now, as I want to buy it )!

Can it be that currently, LXConsole does not react to "/key.lxconsole/G" ? If so, could that be enabled? and is there a way to permanently dismiss the confirmation dialog when adding a Group by reference in Live?

Hi Claude,

I am digging this one out again, as I am faced with a situation that seems to call for the reversal of how the dynamic Group feature is applied:

I am working on a show that is touring, has very limited amount of tech time (unfortunately, BOTH in the first instance, as well as in subsequent venues), and I am looking at a cue sheet that goes a bit like:

LX 7 - repeat LX4 (but with different fade times and potentially follow-ons)
LX 7.5 - repeat LX 3
LX 8 - variation of LX 3 (meaning a repeat of LX 3 plus some changes in the cue)
LX 9 - repeat LX 3
LX 10 - variation LX 4 (meaning a repeat of LX 4 plus some changes in the cue)

I am looking at a way of teching this quick and reliably, and a combination of tracking and dynamic inclusion of Groups comes to mind (though I am a bit scared !)...

CASE 1

LX 7 - this would call for a block cue, and a dynamic inclusion of Group 4 (I would call the groups for ease of operation by the same numbers as the original cue number where they occur) -

Question, is there a way to edit Groups in Live mode? As in, whereby going into the Groups tab does work like working in Live as opposed to working in Cues? If not, I would assume the workflow to be to go into the original Cue, LX 4, which would be empty except for dynamic Group 4 in live, change what needs to be changed, and record group 4, BUT - when/how is it decided which channels are included in this record/update? all non-zero values in live? every channel that we have selected? or do they have to be consciously marked?

CASE 2

LX 7.5 - repeat LX 3

Solution: block cue, then recall dynamically Group 3, easy

CASE 3

LX 8 - variation of LX 3 (meaning a repeat of LX 3 plus some changes in the cue)

Solution: because of tracking, I don't need to include Group 3 here, just record the changes into LX 8, where necessary, they should override the contents of Group 3

CASE 3

LX 9 - repeat LX 3

Solution: as there is no way of telling what tracks from where, I would need to have once again a block cue for a clean slate, then dynamically recall Group 3

CASE 4 - the crux

LX 10 - variation LX 4 (meaning a repeat of LX 4 plus some changes in the cue)

The issue: I can affect channels that are not included in Group 4, but where it gets difficult is where I need to affect channels that are included in Group 4, as these will be overridden by Group 4. In the past I have suggested altering this, and understand that the way ASCII standards look at Groups, this is how the hierarchy should be applied. Within the way that dynamic groups are currently implemented in LXConsole, do you see any way of achieving this? Or do you see any chance of adding a modifier to the way dynamic Groups are applied (i.e. FIRST apply the contents of a dynamic Group inclusion, THEN apply values within a cue as LTP) - not suggesting syntax here, but going Gf nn instead of G nn?

In Case 2 and 3, something similar works, but I don't think I would be able to solve the fact that you would be looking at two fade times, if I do not at any stage WANT to see the pure Group 4 contents live, correct?

We are teching this Saturday, and any help or hint before that would be greatly appreciated.

Needless to say, the goal is to prep the show file, and at each tech JUST re-record/alter the recorded Groups and the variation cues, to speed things up.

Cheers across the ocean!

On a related note, is there a way to switch on or off Block Tracking for a cue in Applescript?

While this might be a bit hard/far fetched - would it be possible to achieve what is desired by creating a cue in between that is not executed? Would the tracking mean that even if the cue is not executed, the included Group levels would track through to the next cue that IS called?

edit: I have removed this request because it really touches on something bigger than this topic.

I'm not sure I see why you want to use tracking when most of the example cues include a block (which is the way regular non-tracking works). Tracking updates dynamically and it is very easy to make a change and have it track through a bunch of cues that you did not intend. When you don't have a lot of time, there's potential for tracking to cause more problems than it solves.

Included groups are added to a cue in the order they are listed in the advanced tab of the Inspector. So, for your cue 10, you can include group 4 first and then include a group 10 that modifies the levels of the channels in group 4 that you want to override.

In order to update an included group, bring up the cue that includes the group. Make your modifications. Then use the "Update group:" command (capital "U") to update the group. In your example cues, there is a repetition of cue 3 included in cue 3 and other cues as group 3. You would go to cue 3 in live mode. Make adjustments to the channels that are included from group 3. Then use "Update group: 3" to copy the changes back to group 3. Update group only copies levels from the live cue back to the group that are marked in the group and being included. Other levels are not changed. So, if cue three used other channels that were not coming from group three (and you modified them), you'd need to re-record cue three in addition to updating the group in order to capture the changes.

Say you have cue 10 that includes both group 4 and group 10 (with group 10, as in the possibility mentioned above, overriding some of the channels in group 4) You'd want to be careful not to use "Update group: 4" after playing back cue 10 because this will cause the channels being overridden by group 10 to be copied into group 4. Update group copies the levels back to any channels that are marked in the group specified.

In the latest build (8904.1) the "Update group:" command can be used without a group being specified. This will update all included groups in the reverse order they are added. You could use this with the last example after playing back cue 10 because the levels that are included from group 10 that override group 4 will only update group 10, not both groups 4 and 10.

In the latest build blockTracking is a property of a cue exposed to AppleScript.

Thank you so much, that makes a lot of sense - brilliant solution and additions, appreciated! Will go through the list and check if that solves it all, and I can get away without tracking - you are right, it always does make me a bit apprehensive working with tracking.