Light Cue Fade In Fade Out

[Bram]

Hi beehive!

I would like to create a light cue with different FadeIn and FadeOut time.

Can somebody help me out plz?

Thanks in advance,

Bram

[Jean-Etienne Bettler]

Hi

you’ll have to create 2 different cues with an auto follow. or you can change the curve shape, but I rather create 2 cues…

cheers

--
Contact support anytime: sup...@figure53.com
Follow QLab on Twitter: https://twitter.com/QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/6007bcd1-a084-481a-976c-dd70d4eec209%40googlegroups.com.

[Bram]

Thanks for the suggestion aroom.

In fact, I think it would be great if this feature would be implemented in a future version of Qlab.

It could really speed up our workflow imo.

We are all used to this by working that way on our light consoles ;-)

Have a good one!

Bram

Op vrijdag 21 februari 2020 17:42:28 UTC+1 schreef aroom:

Hi

you’ll have to create 2 different cues with an auto follow. or you can change the curve shape, but I rather create 2 cues…

cheers

On 21 Feb 2020, at 16:01, Bram <bram.van...@despil.be> wrote:

Hi beehive!

I would like to create a light cue with different FadeIn and FadeOut time.

Can somebody help me out plz?

Thanks in advance,

Bram

--
Contact support anytime: sup...@figure53.com
Follow QLab on Twitter: https://twitter.com/QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "QLab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ql...@googlegroups.com.

[Philip Glenn]

I’m not sure how you think it would be implemented. What would a fade out time do? A fade out cue would still need to be created. 

Philip

On Feb 21, 2020, at 12:10 PM, Bram <bram.van...@despil.be> wrote:



To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/1d34ba45-caf1-4867-a422-4154af821e99%40googlegroups.com.

[aroom]

we could have an option to automatically create two different cues with an auto follow or in a group with an auto follow (I already suggested this here: https://groups.google.com/d/msg/qlab/REI_e_J_BgM/BGF9cBaoAwAJ)

something like:

- right clic on the light cue, or an option in Basics

- set the option for time out

-and let QLab create the second cue and/or the group

having a different time in and time out is really common in light design

aroom

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/1d34ba45-caf1-4867-a422-4154af821e99%40googlegroups.com.

[Richard Williamson]

Creating separate cues would get very messy when edits are made - I’m not sure why there can’t just be separate fields in a timing section of the editor where up/down/focus/colour/beam times and delays could be entered - just like any normal lighting console. It’s such a basic (and important) feature that to lack it is a massive omission 

Sent from my iPhone

On 22 Feb 2020, at 09:01, aroom <aroo...@gmail.com> wrote:



To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/b23b2ea9-a932-4cf8-bb0a-5c7d43890ea4%40googlegroups.com.

[Nathan Schroeder]

To be clear to those newer to lighting control: He's not saying: I want to specify on cue X the time cue X takes to fade in, and also the time Cue X takes to fade out. No. He's saying: I want to specify on cue X the time taken by those lights that are coming on or changing in cue X, and separately the time taken by those lights that are going off in cue X.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/b23b2ea9-a932-4cf8-bb0a-5c7d43890ea4%40googlegroups.com.

[Philip Glenn]

Ah!!

Philip

On Feb 22, 2020, at 4:09 PM, Nathan Schroeder <nat...@ramserv.com> wrote:



To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/1fd11aee-dfeb-4a2f-aaee-589e4024b368%40googlegroups.com.

[Chris Ashworth]

Hi Nathan,

I’d be curious to learn more about what your description means — to me this sounds the same as saying different times to fade in and out.

Regarding Richard’s question about why there can’t just be separate fields in a timing section, I imagine there could be, but also think that it’s not as cleanly straightforward as just adding them; much of QLab is designed around the expectation of a single duration per cue (e.g. hotkey editing the duration of a cue in the cue list) and so there are design questions to answer if we decided to go the route of having one cue take different times for different things inside it.  (Which, of course, is what a group cue allows one to do today, just by having the separate components split into their distinct pieces.)

-C

[Richard Williamson]

The problem (for me) with not having this option is that as a lighting designer it is massively rare for me to have the same time for a cue going in and out - generally I want lights to fade out slower than the new ones come in. While splitting channels into separate cues for each direction is possible this would take massively more time than usually exists - on an eos I can simply type “time 1 / 3” and I have an up time of 1 and a down time of 3, I can even type “time 1 time 2 time 3 time 4 time 5 enter” which gives me an up of 1, down of 2, focus of 3, colour of 4 and beam of 5. To have to manually split the cue into separate parts (and then remember to do this again if I edit the cue itself, or any of the preceding cues which track up to it) takes time that generally doesn’t exist in a tech. Similarly delays can be set in the same manner.

Often during tech we will run a cue and the timing won’t be quite right - so we will quickly adjust it and then run it again. To ask the whole company to stand around while I move channels between parts of a group would just be embarrassing.

While I appreciate the point regarding the duration, I would contend that the separate time tab would still mean that the “duration” field was similar in use to that in an audio (or video) cue where there duration is a calculated field, made up of the contents of the cue. 

If you followed the eos model then the “duration” would by default be the same as the fade time, however as soon as some of those fade times were edited the duration field would become calculated and either be locked, or offer a prompt when edited to scale existing times or change all)

The ability to set times such as this is so key to the lighting design world that I personally feel the slightly more complex UI is worth the feature

Richard

--

Richard Williamson

www.richard-williamson.com

ric...@theatre.support

+44 7957 457 362 

-- 
Contact support anytime: sup...@figure53.com
Follow QLab on Twitter: https://twitter.com/QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups "QLab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/CADv1a49hvG-UimGHdXh0CwFKxYYELjSAmnXweN4HdD2Ze0tuZA%40mail.gmail.com.

[Chris Ashworth]

All makes a ton of sense, thank you for this description Richard!

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/1AF595EC-2E48-42EA-A2E4-650075B31036%40theatre.support.

[Mike P]

I’m speculating a little wildly here and I don’t have the actual history of how lighting consoles developed at hand, but as with most useful software, I believe there was an evolution based on the needs of the process.  The development of QLab has always exemplified this idea, but for different purposes than Lighting Programming.

I’m also speaking of consoles with linear execution in mind, rather than something like a “busking” system used in concert and corporate designs.

The ability to have separate fade in and fade out times for a single cue, which I’ve always referred to as a “split fade,” dates back from some of the earlier computerized lighting consoles such as the Strand Light Palette line of the 1980s.  It was a way to allow control channels that were increasing in level (going up) to operate in one time and those that were decreasing (going down) in another.  It was an evolution to allow finer control of the action of a cue.

From there, other timing possibilities such as “Wait” or “Delay,” the ability to pause before executing a cue, were added for even more control.    Then you could have an Up Delay separate from a Down Delay for more specificity.  Those foundations, as Richard pointed out, have become a critical function of the Lighting Designer’s workflow during the heat of a tech.  

Enter the Part cue, where you can take a single cue and break it up to operate on different channels using different times.  This allowed for the unprecedented ability to do two things at once for consoles where tracking wasn’t yet cleanly implemented.  Anyone who has programmed an Expression with them can tell you they were a godsend.  Split Fade and Delay controls can be applied to each part giving very fine control.  Automated fixture attributes (color, focus, et. al.) were also given separate timing control as Richard also mentioned 

The whole paradigm evolved over time into what we now have that make the LD and Programmer’s work flow into as efficient a process as it can be without having to suffer a learning curve when you have a dozen actors, the director, several other designers and operators all waiting for you to get your console to do that one small thing that makes the moment work.

In my mind, QLab’s Group construct applied to lighting is analogous to Part cues and for me, the effort to manage them is different, but not more difficult.  However, QLab has never evolved to allow for the specific timing controls LDs have ingrained in the process.  It’s never needed to.  So it’s a struggle to adopt a new system which does not give the ready control from the old.

I imagine adding those timing features within a cue is a monumental task given that QLab evolved along different lines than something like ETC’s EOS.  However, for the most part, LDs who work with the established consoles will want that capability and will gravitate away from QLab in favor of what they know will get the job done.  That being said, I’m seeing QLab’s Lighting package starting to gain a foothold and am incorporating it into my programming classes as an alternate system so my students are aware of it.

Mike Post

mdp...@mac.com

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/CADv1a4_1Y8wVLHCUP3UtZ_9%2Bo2hwLmug9sDum12JcU-hRhnJTg%40mail.gmail.com.

[Johan]

Agreed.

Im one of those who "will gravitate away from QLab in favor of what they know will get the job done".

But if the job is simple enough I can recommend also Qlab and I know many who use it for small shows.

Its very convenient for touring but needs a few hours more to prepare, just at the moment when you absolutely don't have that extra time to spare...

And thanks for your brief tech history Mike. :-)

I think we also need to mention the reason for all this fiddling with times in and out that soundguys rarely encounter as a problem in a live situation.

Its all more or less to avoid dips and unwanted coloureffects and its a problem we´ve had and solved in similar ways, also in different analog and mechanical systems for about 500 years now.

When one light goes down from 100 to zero while another goes up from 0 to 100 in the same time, they will meet at 50 % and thats what we call a dip.

- It gets darker for a short while and then brighter again. Rarely a desired effect.

The problem with dips can get worse if the lights hit different areas and/or are in different colours.

Nowadays we also have the moving lights to consider and its very seldom we want their movements from A to B or different effects moving in/out to have the same time as their fades up/down.

In Qlab you have to think it through a bit more and make some more cues for the things that a lighting console saves in each single cue and importantly: - thus affects all cues independant of in what order you choose to play them.

But I guess one can get used to that as well , even though it feels like an awkward workaround just when that's the last thing you need.