Documentation / Manuals

Hi Rando -

You seem to already have a good handle on the data structure of Congo as it is similar to other consoles that control moving lights. For the benefit of others, though, an annotated version is provided below...
 

1) DMX gets patched to channels.

A channel is a dimmer, a bunch of dimmers, or a device such as a moving light or media server.

Channels have levels for intensity and/or parameters.

Channel selection and intensity levels can be recorded into groups (groups are one kind of record target). Groups are not referenced by any other record target. Groups are typically used for quick channel selections, but may also be used to recall specific intensity states. 

Parameter levels can be recorded into palettes (another type of record target - of which there are 4 types - Focus, Color, Beam (which filter automatically to that type of data) and All, which can contain focus, color and beam data in one target.) Palettes can be referenced by Presets (meaning if you update the contents of a palette, any preset you have recorded will get that new data when played back).

Presets (yet another type of record target, and the typical building block of a show) contain the "stage look" and can contain channel levels directly for intensity or parameters, or can contain palette references for parameters. Presets typically contain all active intensity levels at the moment of recording. The method Congo uses for recording parameters into presets defaults to recording only changed parameters, but this is a user setting and can be changed to a number of different options.

Sequences play back presets in a specific order (any order, actually).

The Play List can create a stack of sequences to play back in any order and blend one into the next seamlessly on the Main Playback.

2) This one is simple. Intensity is always handled HTP (highest takes precedence) among all playbacks, and parameters are handled in LTP (last takes precedence) fashion. The only exceptions to this scenario are 1) Parked levels for intensity and/or parameters take top priority, 2) Independent Exclusive control of intensity levels - the 6 faders and 3 switches when set to "Exclusive" will take precedence over the keypad and playbacks , 3) Capture Mode for manual control - captured levels (intensity and parameters) take precedence over playbacks.

So, as far as who is "winning" control over intensity, usually all you have to do is select the channel(s) in question and the gold box surrounding the channel in the Live display will indicate the HTP winner for that channnel. AB indicates the Main Playback. A number indicates the Master Playback with the highest intensity level for that channel. An "In"  indication means that an Independent fader or switch currently has control.

For parameters, these are handled entirely LTP, meaning that nobody owns a parameter once it has been given a command. The only exception to this rule is for parked and/or captured parameter levels, which get held at high priority following the same rules above. Independents may activate parameters, but they do not hold onto those levels.

Essentially, if one performs a 0 GOTO and brings all active masters down, nothing should be left on stage. It is possible, though, to have dynamics continue to run since a 0 GOTO is really an intensity command (there are no move instructions in the 0 step to cause movers to move). In this case, one can either delete the dynamics manually using the softkeys or the Live Dynamics tab, or one can write the first step of the main sequence as a GoInB step and force it to stop all dynamics by inserting the STOP I, STOP F, STOP C and STOP B dynamics on all channels in that first preset.

Congo offers very flexible playback options and a very simple set of rules for negotiating the actual output. I will suggest that these items be added more clearly to the user manual in a future version, though.

I hope this helps -

Thanks -

Sarah
 

Sarah,

Thanks! This is helpful. I'll reply to the two questions separately since maybe it isn't fair to include two in one posting!
 
On Q#1, [the hierarchy] thanks for confirming my understanding. Thing is, it took me some time to understand that and it might be useful to have that in the documents. Also, I think a picture would be a good way to show it--it seems odd to me that the Congo interface is clearly directed to people who think visually and spatially, but the documents seem to have more words than pictures. Just a hopefully helpful suggestion!

Also one point that is a nice feature (but different from other consoles) is sequences do not include presets, but only references to them (in software lingo I'd call them pointers), which makes them analogous to the way presets include channels--i.e. if you repatch after recording a preset, the dimmers currently patched to the channels are referenced, not the ones patched when the preset is recorded. It's elegant because it makes the data structure similar at different levels, although it can throw you off if you are not used to it.

 

Presets really are a "building block" in that they are completely referenced and reusable and can be used like groups. Presets on Master Playbacks are like submasters on other consoles. You can recall the levels from presets by pressing # PRESET, to select channels with intensity in that preset, or use # PRESET & @LEVEL to select those channels and recall their recorded intensities as well.

With selected channels, you can press # FETCH & FOCUS (or color or beam) to recall the parameter data from a preset. If that preset is in the main playback at the time, the accumulated state of the attributes of those channels will be recalled.

You can pile presets or parts of presets on top of each other in Live using these methods and then record that combination as a new preset. They are really quite useful for a lot of things.

In the most basic use, however, they can be considered "cues" - though in Congo a cue is an event (a preset recalled by a sequence step) not a target. 

I'm glad you found this helpful -

Thanks! 

Sarah 

Sarah,

Thanks again for the replies! I was hoping some board user had developed some "cheat sheet" references they would share, but it is amazing to get a response directly from ETC!

 But since you are "on the line" so to speak, can you address the sad state of the Congo documentation? It is the one thing I mentioned that you didn't address. Again, I am not trying to criticize as much as point out areas for improvement. I've developed products before and understand sometimes it is difficult to produce good documentation when the product is still in flux, but I've been hoping for an update now that the Congo seems to be maturing.

In particular some things I have found:

1. Missing concepts that are important. For example, your earlier email mentioned "record targets" (there being four) and presets as "completely referenced" and "reusable," and these phrases help a lot but do not appear in the manual that I can find.

2. Confusing and inconsistent references. Some ideas are called different things in different places, and some ideas are not defined. For example, the terms "mapped" and "connected" seem to be used in similar context a lot, but not clear if they are equivalent. One of the most frustrating is the phrase "channel control(s)" which is used a lot but never defined that I can see. (as in "channel controls are mapped to the A field"--"A field is not defined either).

3. A few genuine errors. The one that sticks out the most is that DMX has 256 bits. DMX actually has 8 bits per data slot, giving 256 levels. Using the wrong terms isn't helpful to anyone new to DMX, and confusing to anyone with experience. Later, in reference to scrollers and moving light course/fine adjustment, the (correct) 8 and 16 bit terms are used.

4. A need for overall good editing. (I know a good editor if you need one). There are so many errors in spelling and grammar, misused words, shortened words and placeholders. Again, I know those are hard to fix in early versions but it reflects poorly on the product to have rough documentation so late in the development cycle. I'm not the only lighting designer or tech who is more than annoyed at bad editing--it makes me wonder if the lack of precision and attention to detail carries through to all aspects of the product!



 

Sarah,

Thanks again for the replies! I was hoping some board user had developed some "cheat sheet" references they would share, but it is amazing to get a response directly from ETC!

 But since you are "on the line" so to speak, can you address the sad state of the Congo documentation? It is the one thing I mentioned that you didn't address. Again, I am not trying to criticize as much as point out areas for improvement. I've developed products before and understand sometimes it is difficult to produce good documentation when the product is still in flux, but I've been hoping for an update now that the Congo seems to be maturing.

In particular some things I have found:

1. Missing concepts that are important. For example, your earlier email mentioned "record targets" (there being four) and presets as "completely referenced" and "reusable," and these phrases help a lot but do not appear in the manual that I can find.

2. Confusing and inconsistent references. Some ideas are called different things in different places, and some ideas are not defined. For example, the terms "mapped" and "connected" seem to be used in similar context a lot, but not clear if they are equivalent. One of the most frustrating is the phrase "channel control(s)" which is used a lot but never defined that I can see. (as in "channel controls are mapped to the A field"--"A field is not defined either).

3. A few genuine errors. The one that sticks out the most is that DMX has 256 bits. DMX actually has 8 bits per data slot, giving 256 levels. Using the wrong terms isn't helpful to anyone new to DMX, and confusing to anyone with experience. Later, in reference to scrollers and moving light course/fine adjustment, the (correct) 8 and 16 bit terms are used.

4. A need for overall good editing. (I know a good editor if you need one). There are so many errors in spelling and grammar, misused words, shortened words and placeholders. Again, I know those are hard to fix in early versions but it reflects poorly on the product to have rough documentation so late in the development cycle. I'm not the only lighting designer or tech who is more than annoyed at bad editing--it makes me wonder if the lack of precision and attention to detail carries through to all aspects of the product!



 

Hi Rando

I'm Ulf Sandström - I'm responsible for the manual in every way possible and part of the Congo development team. I'd like to ask some questions and provide some thoughts.

1. Missing Concepts
As far as I understand you found the concept of Presets being referenced hard to grasp from the existing documentation?

It would help me to know a few details about your learning process.
- What consoles have you been using prior to Congo?
- Have you read the Quick Introduction and the Presets - Introduction chapters?
- When you didn't find the data flow you looked for, how did you approach learning the system?
- Did you try to learn the system using the online manual that is context sensitive - or a paper manual?
- Did you have the system up and running when you were reading up on it?
- Have you watched any of the tutorial movies?

2. Confusion and inconsistency
When it comes to the A field I'll agree that this isn't as easy to find as it should be - being a central part of the concept where we have no programmer. This will be adressed. Apart from this and the terms "mapped" and "connected" - what did you find confusing?

- Have you tried the search function?
If you search for Channel Control you get Channels - Introduction where this is explained. A lot of users find this function helpful. 
- Could you give an example of where you find the terms "mapped to" and "connected to" confusing or unclear?
- Apart from the terminology - did you find the concept of not having a programmer hard or easy to understand?

3. A few genuine errors
You are right, it should read bytes instead of bits. Thanks. What other ones are you referring to?

4. A need for overall good editing
- Could you provide some examples that are more specific than this very general description?
At best - use the "favourites" function where you can leave me comments and mail me the file "p_default.mdb" in the directory 
"CONGO\OHD\p_default.mdb" this way I will know exactly what you mean.

 Looking forward to hear from you

 All best

Ulf Sandström

Hi Ulf!

Thanks for the reply! I didn't mean to be too hard on your manual--I can see that it is a very difficult task with such a complex machine as the Congo, and also I don't intend to be critical of the Congo (it's a nice console). But I have been involved in product and manual development in the past, so I know sometimes the team gets immersed in the terminology and it can be helpful to get the perspective of someone fresh to the product. That's the spirit of my feedback--trying to provide my perspective as a new user and make things better.

Of course I also have to say that I don't know that my way of approaching a new console is similar to anyone else's, so can't say if my comments will help all users, some users, or only me. But in general I've found that consistency and clarity seem to be helpful.

Also I have to say there has been considerable improvement in the manual from version 4.0.4 to 4.3. 

Some of your questions will take me some time to answer, and I will do my best to get those answers to you soon. I don't fully understand your suggestion of using the "favorites" function--does that require that I am at the console or offline editor? Perhaps you could explain or I could email the answers to you?

Some quick answers to questions you asked:

Prior consoles I've used: several, but there are some gaps. Lately mainly have programmed and run shows on every flavor of ETC Expression/Insight. Started out on 2-scene preset 25 years ago, and since have used Colortran, EDI, Strand for conventionals. For movers, I started with the early High End devices (Cyberlight, I-beam) and those clunky LCD controller boxes they shipped. I have some limited experience (1 show each) with the Hog and Zero88 Frog. I've also designed/programmed robotics and scrollers on an Expression 3 and found it wasn't too bad.

In regard to learning process, my approach in all of the above is to read the manual first to get a feel for the design and programming philosophy of the console. Being a designer/engineer myself, I can usually pick that up quickly. Then I spend time hands-on with the console, getting myself into and out of trouble, referring to the documents as needed, until I feel comfortable that I can do what I need to do for the show.

The Congo was the first time that process failed--I spent a long time with the manual both before using the console, and with the online version while using the console. I read the introduction (Quick Intro and Presets). I watched all the online tutorials. Yet I always had the uneasy feeling that I had memorized a collection of facts and key sequences, but not mastered the board to the degree that I felt confident that I could always control the stage picture and devices.

You asked about the data flow and to me that is key--I always have a model in my head of how the data flows from faders to DMX, and when that didn't come from the documents, I just formed it from experimenting with the system. I also sketch it out on paper, so by now  think I have a good picture of the data flow and hierarchy of data in the system.

What bothers me is that I assume that the ETC/AVAB/Congo programmers had to have those models and data flows and hierarchies in hand before programming the system (if not I am really scared!), so it would be useful to share those with users.

Anyway this is growing long. I will gladly later (since you asked) send my thoughts on specific areas of the docs that are confusing, inconsistent, or confused me, hoping that will be useful to you. I don't want to do a detailed edit of the manual for typos, etc. for free, but could point out some problems to show a need to hire a good editor to look it over.

Hi Rando

 
It's all cool. You might be surprised how many different approaches there are to writing and reading manuals - or learning consoles for that matter. I've been doing both since 1986 and there is always a new approach around the corner - none better or worse - all individual, subjective and therefore - valid.

In any case - lets drop out of this forum and mail directly. I can explain the favourites function. This is also a system that was designed from the start to be learned on-line and with electronic documentation. Your method is therefore not the primary target - not saying it's not valid. I can explain this too, and I'll be very happy to learn abut the typos - since a full spell-check has been performed in 4.3 and this then must have failed.

All best

Ulf