Page 1 of 1
EFX duration
Posted: Fri Nov 08, 2019 1:56 pm
by Franzi
Hello again.
Question: if a EFX is running "serial" instead of "parallel" - how can one calculate the total runtime of the effect ?
I have observed that the total runtime then no longer corresponds to the value of the hold time - but
how much exactly? Is this a fixed value or does it depend on which figure you use?
In case, one is using a "tap" to sync to music, it is very hard if not impossible to set to correct
values to the chaser/function at all when combining parallel and serial patterns in one chaser, or am I wrong ?
Thank you.
Re: EFX duration
Posted: Tue Nov 12, 2019 8:17 am
by GGGss
Again ... EFX timing is (a bit) obsolete because you don't know the speed of the tilt / pan moves of your heads.
Theoretical the EFX are based on a mathematical function and therefore you could calculate the exact timing.
Say they do a 360° figure in [timing]-time. 90° or 1/4 of the figure would be [timing]/4
If multiple EFX are in place the outcome would be the f(figure1) + f(figure2) @timing in 2D space.
How would one achieve a serial EFX? A chaser with 2 EFX with hold time running each after the other?
Theoretical you could calculate it's outcome but again - this is completely hardware dependent (!)
(and what you think happens when your tap-speed is way faster than what the heads can physically do? Mayhem)
I often see guys doing beautiful (theoretical) timecode programming and then in live mode, the outcome is utter chaos...
Re: EFX duration
Posted: Tue Nov 12, 2019 10:12 am
by Franzi
For an efx < max. speed, you´re right. But that´s not my usual use-case.
> How would one achieve a serial EFX?
I meant the checkbox in the efx - editor, not combining two efx in sequence
So my question was: whats the 'offset' for this option - if known at all. Is it fix ?
Is it calculatetd ?
It´s hard to program things if you don´t know about the underlying timing, I think.
Re: EFX duration
Posted: Tue Nov 12, 2019 10:16 am
by GGGss
Franzi:
"Serial: fixtures start following the pattern one after the other, with a little delay between each of them." As per
https://www.qlcplus.org/docs/html_en_EN/efxeditor.html
This option give you the possibility to 'fan' your effect
Re: EFX duration
Posted: Tue Nov 12, 2019 1:46 pm
by Franzi
> with a little delay between each of them
That amount of "little" is what I asked for...
>> Is it fix/static ?
>> Is it calculatetd ?
Do the "delay" depend on the overall fade+hold time and/or number of fixtures or is it static/fixed ?
Re: EFX duration
Posted: Tue Nov 12, 2019 3:27 pm
by Franzi
and, in addition, how can "tap" be used to match the total runtime of an efx ?
is there any way to "recalc", "precalc" the time before passing it on to the efx ?
I mean, with fixed multipliers / divisors there is a high probability not to fit, right?
Re: EFX duration
Posted: Thu Nov 14, 2019 11:00 am
by GGGss
Franzi,
I understand your passion and your willingness to get insight.
In the end it's the heads who will or will not succeed in what your thinking off.
There are very fast heads and very slow ones. In function of what needs to be lit, one chooses one type (f.i. EDM = fast; drama = slow).
So the amount of 'little' delay - i suppose it will be calculated inside QLC+ and I suspect it will be some degrees (vs 360°)
I never did time it but I saw it in real life. If you make groups of 2 with serial then the 2nd of the group of 2 will start just a bit later. And No this is static timing.
When I don't like the outcome on stage; I will change the sub division degrees inside the EFX.
'delay' depends on the timing of the whole cycle I presume.
'tap' does not match the total run time. It is vise versa - with 'tap' you set the duration of a 360° cycle.
recalc / precalc: If you are referring to BPM etc you could recalculate with a sheet of some kind. Beats per minute vs time per bar.
Why shouldn't it fit? It all depends on what you want as a lighting outcome. Some effects are nice with a certain kind of music; some work erratic. It all comes with your taste...
Do you possess some heads? Well check for yourself... you will quickly discover the influence the hardware has onto the idea you think it should be.
Timecoding lights is a precision job and depends hugely on acc- deceleration and movement speeds of the heads in use. This deviates hugely in the theoretical world.
Say you want 8 heads to arrive at the same time on the end position... good luck with that in the real world...