Control/Dimming Stupid Ion Questions 1

Jay Ashworth

Well-Known Member
Very late in the game now, I admit, I finally got my fingers on an Ion this morning, v2.2, and running in cue-only mode to my surprise -- the guy whose it is says he's never found a need for tracking, doing theatre, dance, and light concert (jazz and symphonic) -- and there were a few thing I didn't quite get.

I've read the 2.0 operators manual, and my overarching impression is that it was written for experienced LDs, who know *why* you might want to do a thing that's best done with a specific function... but not at all for people who don't know what you might want a specific function for; it doesn't explain much of anything.

So, before I get into the stupid questions -- and yes, I've watched (most of) the Disc one training videos as well; they have the same problem, largely, and also handwave in some spots I'd *really* rather they did not -- is there any "tutorial" training on the Eos series software package anywhere, as opposed to the reference material that ETC produces? Surely I'm not the last guy left who's going to learn how to light with an Ion, with the emphasis on "how to"... :)

Anyways:

I have a handle on why subs lose control of the channel values (well, HTPishly, anyway) when you build a cue from them, and hence you can make things brighter but not dimmer from the submaster, and how to use Group Sub to get around that.

What I was less clear on was why GotoCue 0, which was the way recommended to me to clear out a loaded cue so you could start clean programming the next one if you wanted to, *does not actually cause the desk to stop saying that you have a Live Cue, whichever number was last*.

Is that cue still Live, even though the lights are out?

I could understand that if I'd used Sneak, say, to get out of the cue (though I can't lay claim to understaning Sneak either), but I would have thought that goto0 would clear that.

Deleting the current cue, interestingly, *does* cause that indication to go away... but does *not* cause the cue to fall off the channels.
 
https://www.youtube.com/playlist?list=PLl-Ao0hIFwH_7sGnpmWE-p9J22DtT--Eg

And I would highly recommend updating to 2.4, the newest of the software.

[Go To Cue] [Out] [Enter] Is my preferred method for making sure live output is halted, But if nothing is being reflected on stage you are technically good.

Sneak, is basically what people would recognize as release, It clears manual values, (the red numbers) and restores the look to its background state, in your case, probably the currently live cue.

Correct, deleting the cue will remove it from the command line but not the live output, however, it will continue to output the contents of the cue if I'm not mistaken.




Sent from my iPad using Tapatalk
 
You know, I've never noticed that go-to-cue{0,out} left the cue 'active" in the PSD, but now that you've mentioned it I'd have to think it was a bug. Sneak will not leave a cue, it only effects manual data. (Either releasing it by default, or you can do something like Chan 5 @ 50 sneak time 5 to further control what sneak does.)

There is a bit of a learning curve to the eos, but my experience with it all along has been one of finding that the console really speaks fluent english. Usually the way you'd expect to tell the console to do something is the way it responds to.
 
You know, I've never noticed that go-to-cue{0,out} left the cue 'active" in the PSD, but now that you've mentioned it I'd have to think it was a bug. Sneak will not leave a cue, it only effects manual data. (Either releasing it by default, or you can do something like Chan 5 @ 50 sneak time 5 to further control what sneak does.)

There is a bit of a learning curve to the eos, but my experience with it all along has been one of finding that the console really speaks fluent english. Usually the way you'd expect to tell the console to do something is the way it responds to.

Yup, It's the only real conversation I have these days. Haha


Sent from my iPad using Tapatalk
 
I may talk him into upgrading to 2.4, but then, I might also talk him into The Big Upgrade; we'll see.

I'll pay closer attention to channel colors next time. The monitors are offside right now, another thing I'm working on, along with touch.

Sent from my SGH-M919 using Tapatalk
 
Go through the 'tea break' tutorials. I find they are more tuned to 'how to'. WHY to do things a certain way is a really complex discussion.

Sent from my SM-G900V using Tapatalk
 
Very late in the game now, I admit, I finally got my fingers on an Ion this morning, v2.2, and running in cue-only mode to my surprise -- the guy whose it is says he's never found a need for tracking, doing theatre, dance, and light concert (jazz and symphonic) -- and there were a few thing I didn't quite get.

...

1) I have a handle on why subs lose control of the channel values (well, HTPishly, anyway) when you build a cue from them, and hence you can make things brighter but not dimmer from the submaster, and how to use Group Sub to get around that.

2) What I was less clear on was why GotoCue 0, which was the way recommended to me to clear out a loaded cue so you could start clean programming the next one if you wanted to, *does not actually cause the desk to stop saying that you have a Live Cue, whichever number was last*.

Is that cue still Live, even though the lights are out?

3) I could understand that if I'd used Sneak, say, to get out of the cue (though I can't lay claim to understaning Sneak either), but I would have thought that goto0 would clear that.

4) Deleting the current cue, interestingly, *does* cause that indication to go away... but does *not* cause the cue to fall off the channels.

I do theatrical and dance lighting as well - and have absolutely no use for tracking mode. To me, the only time tracking is useful is when only a few channels change values with each new cue.

I have numbered the questions to which I am responding. This is all from the viewpoint of using Cue Only mode.

1) Subs are HTP by default, not LTP. You might look at it as a "pile on" function. So if you have a level programmed in a channel that is also controlled by a Sub, raising the sub will not have any effect on that channel until the sub level for that channel is higher than the otherwise programmed channel level.

Since the sub is HTP, if you then reduce the sub below the otherwise programmed level, the channel returns to the otherwise programmed level - since the sub level is no longer highest.

You can use a submaster to reduce a channel level - configure the sub as an inhibit submaster.

2) When you use Goto Cue 0, the status display should not show any cue as the pending cue. For some reason, ETC has not made it easy on novices by having the current cue show as Cue 0. That is a trivial display change that would make the status display less confusing.

No, the cue is no longer active/live. If you press the Go button - the first cue in the cue list will run - not the cue that was active before the Goto Cue 0 was performed.

3) Sneak does not take you out of a cue - it only removes any manual level changes made after the cue was activated. If you are in a cue and decide to make some level changes - then, before updating the cue, decide you don't like the changes - pressing Sneak Enter returns you to the original cue levels in whatever time you have set for the Sneak function. You can also sneak in a channel level change to the active cue.

4) Yes, deleting the active cue from the stack does not eliminate the active cue - just the cue as programmed. If you were then to press Goto Cue xx Enter (where xx is the number of the just deleted cue), you would get an invalid cue message, as that cue is no longer programmed.
 
Some annoying corrections and/or clarifications:

  • Intensity on Subs is HTP by default. Non-intensity parameters are always LTP. HTP is applicable only to intensity. This is crucial to understand when working with color mixing fixtures.
  • On Goto Cue 0, the pending cue on the fader should be the first cue in the active list, since pressing Go will advance to that cue. Anything else would be misleading. If you want nothing to show then release the cue list from the fader.
  • I have no use for Cue Only mode. Embrace the Move/Fade paradigm. (let the battle begin :twisted:)
 
I do theatrical and dance lighting as well - and have absolutely no use for tracking mode. To me, the only time tracking is useful is when only a few channels change values with each new cue.

Well, that's often the case, but as far as I've been able to tell, the primary advantage of running the show in tracking mode is being able to run long cues in the background (a sunrise, for example, that takes 5 minutes), and run "normal" cues atop them.

I have numbered the questions to which I am responding. This is all from the viewpoint of using Cue Only mode.

1) Subs are HTP by default, not LTP. You might look at it as a "pile on" function. So if you have a level programmed in a channel that is also controlled by a Sub, raising the sub will not have any effect on that channel until the sub level for that channel is higher than the otherwise programmed channel level.

Since the sub is HTP, if you then reduce the sub below the otherwise programmed level, the channel returns to the otherwise programmed level - since the sub level is no longer highest.

"otherwise programmed" isn't quite the issue -- the issue is "once you save the cue built atop darkness by the submasters, *that cue is competing to send levels HTP to the channels*". It becomes the Now cue, to use language I introduce below. That's not initially obvious; I'm pretty sure the Smartfade doesn't work that way, for example, so it takes some getting used to.

'You can use a submaster to reduce a channel level - configure the sub as an inhibit submaster.

I'd seen that mentioned; I'll have to look at it.

For my purposes, I strongly suspect it will have additional attached semantics that will make it a bad choice for me.

My real problem is that what's stored in the cues is *channels*, not subs, so there *is no way* that you could make the subs live when a cue has been recalled, in the manner in which the Smartfade does, for example -- you don't have the necessary data stored.

Unless my memory has badly failed me, what goes in the cue memories in the smartfade is submaster@level, not the individual channel levels, so when you load a cue, you can run a submaster up and down to regain control of that group of channels, adjust to taste, and then resave.

2) When you use Goto Cue 0, the status display should not show any cue as the pending cue. For some reason, ETC has not made it easy on novices by having the current cue show as Cue 0. That is a trivial display change that would make the status display less confusing.

No, the cue is no longer active/live. If you press the Go button - the first cue in the cue list will run - not the cue that was active before the Goto Cue 0 was performed.

I strongly suspect the issue here is one of language.

What we're talking about is the Now and Next cues, on whichever playback is live -- usually the Master Crossfader (which itself might be called something else by ETC that I haven't learned yet :)).

[Delete][Enter] deletes the *cue* which loaded the Now cue (when it was still the Next cue), but doesn't *clear out* the Now cue.

The problem is one of modeling: the descriptions in the manual do not allow you to build a mental model of what's actually happening which is accurate.

It's a common problem when they try to "make the documentation easier to understand", and it's almost always the wrong solution, and it gives me hives.

3) Sneak does not take you out of a cue - it only removes any manual level changes made after the cue was activated. If you are in a cue and decide to make some level changes - then, before updating the cue, decide you don't like the changes - pressing Sneak Enter returns you to the original cue levels in whatever time you have set for the Sneak function. You can also sneak in a channel level change to the active cue

Yeah; and I think I have this figured out now. This is for manual changes put into the live channels after the last time a Next cue was made into a Now cue -- by GO, usually.

4) Yes, deleting the active cue from the stack does not eliminate the active cue - just the cue as programmed. If you were then to press Goto Cue xx Enter (where xx is the number of the just deleted cue), you would get an invalid cue message, as that cue is no longer programmed.

And in fact I tried that, and that's what I got. The issue is whether the label just above the command line is showing you the Now cue or the Next cue; it was the Now cue I was deleting, and as I noted above, that deletes the *cue*, but *you've already loaded it into the live channels*, and it doesn't touch those.

Why this all matters is that it determines which ways to get to All Channels Off will actually *work* -- in some situations I've been in, some won't.

Some annoying corrections and/or clarifications:
Intensity on Subs is HTP by default. Non-intensity parameters are always LTP. HTP is applicable only to intensity. This is crucial to understand when working with color mixing fixtures.

I know that, and while we have 4 VLX3's and 4 VLX440's, I haven't gotten to the point of playing with them yet. I do, at least in theory, understand why that's the case, and why automark is good, and I don't quite know yet whether automark works in cue-only.

Cue-only is a really bad choice of name to distinguish these two modes, too...

On Goto Cue 0, the pending cue on the fader should be the first cue in the active list, since pressing Go will advance to that cue. Anything else would be misleading. If you want nothing to show then release the cue list from the fader.

[GotoCue] should load the specified cue into Now, executing the cue immediately when you hit [Enter], right? So you should then end up with a Now that's the cue you specified, and a Next that is the next one in the cuelist [for that playback].

[GotoCue][0] would do this too, but the Next cue would magically be the first cue in the relevant cue list, and the stage should be dark, because cue 0 is magically "All Lights Out". (I recall being told what GTC0 does to non-intensity parameters, but I forget the answer.)

Are those both correct interpreations of the command set?

I have no use for Cue Only mode. Embrace the Move/Fade paradigm. (let the battle begin :twisted:)

Has anyone done a good write up somewhere of what the differences are and -- as someone else concurs with me upthread there's a lack of -- why you would want to use one or the other? [ It seems to me that I've asked that once, and someone posted a link to the board somewhere, and the result didn't actually clear it up for me... ]

Is my summary above too facile?
 
There are several write-ups, whitepapers, and videos about move/fade, tracking, and preset boards and why one is better than the other for __insert use case here__. Most have been cited on this forum several times so use that search box. For me, the paradigm shift mattered once I had to deal with non-intensity parameters and marking, recording and updating cues out of sequence. Inadvertent scroller moves or ML parameter changes become a rarer occurrence once you understand tracking, blocking, and intensity blocking. FWIW, the Ion always plays back as a move/fade console, the Cue Only feature only applies to editing. Cue editing commands accept ranges using the [Thru] key so the use of Cue Only mode is pretty much a convenience for people coming from preset consoles.

One of the things to keep in mind is that every channel can be controlled from multiple sources including cues, subs, pixel maps, and manual overrides. Running a cue at an arbitrary time during a long fade scenario is a simple example. Another more complicated example is busking an ML where the pan/tilt effect is running on one fader while gobos are being bumped through by another cue list associated with a different fader, while the intensity is being managed by the main cue list. On one show I had an automated cue stack for simulated explosions that was synced to the audio via OSC while projections were taking control of the cyclorama light via an inhibitive sub also managed by OSC, all happening while on the main cue list was a sequence of cues following an actor with tight pools of light as he wandered the stage. It takes time to build up the confidence to add something like that to a show. It starts with getting your head around move/fade and thinking about breaking big sequences down into several manageable little challenges that can be run out of sequence to each other. I don't suggest starting with multiple cue lists but it's useful to understand that the console was architected to support it.

My real problem is that what's stored in the cues is *channels*, not subs, so there *is no way* that you could make the subs live when a cue has been recalled, in the manner in which the Smartfade does, for example -- you don't have the necessary data stored.

There actually IS a way but it involves exclusive or shielded subs and macros that sets subs to levels and the {Execute} option on a cue. I typically use it for atmospheric effects where I need a manual handle. However, the preferred mechanism for most cases is referenced data (palettes and presets), which can be directly assigned to faders in v2.4.
 
Last edited:
There are several write-ups, whitepapers, and videos about move/fade, tracking, and preset boards and why one is better than the other for __insert use case here__. Most have been cited on this forum several times so use that search box.

Well, I will, but text searches are notably incompetent at searching for *concepts*, so I might be at it a while. :)

For me, the paradigm shift [started?] to matter once I had to deal non-intensity parameters and marking, recording and updating cues out of sequence. Inadvertent scroller moves or ML parameter changes become a rarer occurrence once you understand tracking, blocking, and intensity blocking. FWIW, the Ion always plays back as a move/fade console, the Cue Only feature only applies to editing. Cue editing commands accept ranges using the [Thru] key so the use of Cue Only mode is pretty much a convenience for people coming from preset consoles.

So, in short, you're saying that when I build cues in QO mode, it simply fills in all the slots for channels I didnt' touch with What Has Come Before -- *as calculated at edit time*?

Cause that's the issue here, as I am beginning to understand it -- in tracking mode, if I go to a cue, the board has to show me the *whole* tableau, and the only way it can do that is to, for each channel, start at that cue, and work backwards until a move tells it where it was supposed to move *to*, be that in the cue itself, or all the way back to the top of the cuesheet. (We will, for the moment, ignore multiple cuelists, and other such complicating schidt...)

Do I understand that correctly?

And in QO mode, the current cue will *always* have a number in every hole in the spreadsheet row?

One of the things to keep in mind is that every channel can be controlled from multiple sources including cues, subs, pixel maps, and manual overrides. Running a cue at an arbitrary time during a long fade scenario is a simple example. Another more complicated example is busking an ML where the pan/tilt effect is running on one fader while gobos are being bumped through by another cue list associated with a different fader, while the intensity is being managed by the main cue list. On one show I had an automated cue stack for simulated explosions that was synced to the audio via OSC while projections were taking control of the cyclorama light via an inhibitive sub also managed by OSC, all happening while on the main cue list was a sequence of cues following an actor with tight pools of light as he wandered the stage. It takes time to build up the confidence to add something like that to a show. It starts with getting your head around move/fade and thinking about breaking big sequences down into several manageable little challenges that can be run out of sequence to each other. I don't suggest starting with multiple cue lists but it's useful to understand that the console was architected to support it.

Another place where being able to compose a *working* mental model of the control flow is critical.

There actually IS a way but it involves exclusive or shielded subs and macros that sets subs to levels and the {Execute} option on a cue. I typically use it for atmospheric effects where I need a manual handle. However, the preferred mechanism for most cases is referenced data (palettes and presets), which can be directly assigned to faders in v2.4.

For this observation, I'm just sticking with "uh, yeah." :)

Thanks; I'll do a little searching.
 
So, in short, you're saying that when I build cues in QO mode, it simply fills in all the slots for channels I didnt' touch with What Has Come Before -- *as calculated at edit time*?
It would be more accurate to say that QOnly records just what changed (exactly as a tracking console) but also updates the subsequent cue to restore the value from the change that was just made.

The rest of your thinking is mostly correct. The console reconstructs the state of all the channels in the rig at that moment. For sequential Go's it's pretty easy. For Goto Q it has to work harder.

And in QO mode, the current cue will *always* have a number in every hole in the spreadsheet row?
Nope. Use blind spreadsheet mode to see how the console is interpreting the record instruction. You'll see that unchanged values (purple) are tracking through from the previous cue. If they were recorded into the cue at the same value they would show up as white and there would be a small 'b' in the block column of the playback status display.
 
Ok, I read the white paper now, and my apologies to the people in the August thread, notably Bill, who were irritiated with me for not getting to it sooner... and it's as advertised not too bad.

There were a couple spots in it that still confused me, and my perception was that it was because it's contradictory, not because I wasn't paying attention, but I might be wrong.

I'll try to capsulize those things in a separate post.
 

Users who are viewing this thread

Back