Scene fade back into solo-frame?

[Sidlomydlo]

Hey. Hey,

I hope I have a simple question.

Let's say I have scene A, which is in solo-frame, and scene B, which is out of frame. I have both scenes set to fade-in and fade-out at 1s. Both control the position of the moving head.

When I turn on scene A in solo-frame, the position comes up smoothly. As soon as I turn on the out-of-frame scene, the transition is smooth again. However, when I turn the out-of-frame scene off, the transition back to the still active in-frame scene is abrupt regardless of fade-out times.

Is there any solution to smoothly transition back to the active scene in solo-frame?

If it's not obvious what I'm after, I'll attach a sample workspace tomorrow.

Thank you all for any advice.

[Yestalgia]

Hey I think I know what you mean.

Unfortunately any scene that is "On" is at 100%. If you share your project I might be able to take a look for you.

There are other options like using Loopback magic.

Kind regards,
Lachie

[Sidlomydlo]

Hi,

thanks!
This problem is part of my (of course not mine, but learned from multiple smart people on this forum) workaround for smooth EFX playback on fader. In solo-frame there are static positions for moving heads and outside it there is a base position scene, cause all EFX are relative. Some loopbacks, fake profile and script is there, I can share this one as well.

But I have only made a simple scene with this particular principle which I haven't been able to solve yet. Maybe you can show me some workaround for this, which I can implement into my main scene and then share my solution working. My goal is to have some smooth transition when I turn the B scene off back to scene A which is still ON in solo-frame.

Thank you very much.

Honza

[giacomo]

Hi, you should report it as a bug,
I've tried with v5, the problem persists also if you put the scene A outside the solo frame.
Only the fade in times are respected, once you switch off one cue the position snaps.

sample5.qxw

(3.3 KiB) Downloaded 115 times

[GGGss]

Which makes complete sense @both...
The active scene isn't reset so how the engine could know that it has to restart fading-in? Because it __was__ active before the new function started? And here we are again asking for a kind of stack tracing.
The only solution I see is to put both inside a chaser and do a crossfade. But this changes the whole setup of the project.
Another workaround would be a loopback magic reset to the solo frame and a re-enable of that scene. But again, it will only work in that combination. (A inside + B outside, not C and D)

[giacomo]

@Fredje "The active scene isn't reset so how the engine could know that it has to restart fading-in?"
Yes because there is an ltp instruction active and the cue fading-out has a time.
You say "restart fading-in" and maybe it's a technical point of view of it: from an user perspective there are 2 cues with a fade out time and the engine should use these instructions.
I've added the color in my test and the color fade in/out correctly, the movement not, it's a basic fondamental bug.

[jcwayne]

Generally position channels are set to not fadable and movement speed is controlled by a separate channel. You can change that in the "Channel properties configuration" dialog, accessed from the fixtures tab.

[giacomo]

Hi Justin, I guess you've not tried the file, the cue is fading-in with the movement and snapping the fading-out.
Personally I think it's a bug a cue that follows an opposite logic depending on the in/out time.

[jcwayne]

I haven't, no. I'll do that when I get a chance. I was basing my reply on your statement that:

I've added the color in my test and the color fade in/out correctly, the movement not, it's a basic fondamental bug.

[Sidlomydlo]

Hi,

thank you all!

To be honest, I wouldn't have thought there would be such a bug in v4 (if it is a bug). But the fact is that the fade-out works for colors in this case, only for positions it doesn't. I rather thought there was a mistake somewhere in my setup, but apparently not. I'll try to report it as a bug and maybe Massimo will explain

Making chasers and crossfades is probably not the way to go in my case. But using a loopback to reset a running scene in a solo-frame and trigger its fade-in sounds like an interesting option I'll try to explore.

Of course, at best it's a bug, and if it could be fixed, it would probably make the only thing that really annoys me about qlc+ so far disappear

Thanks!

[giacomo]

When you report it, forget about the colors because in the fixture personality they're meant to fade, I've added the output to your cues to watch them in the 3D view.
The issue is the movement - and probably all the ltp channels - because it doesn't follow the same rule.
If we're "lucky", this is related to this issue where the EFX works only for fade-in times:
viewtopic.php?f=35&t=15940

[Sidlomydlo]

Another workaround would be a loopback magic reset to the solo frame and a re-enable of that scene. But again, it will only work in that combination. (A inside + B outside, not C and D)

@GGGss For basic two-scene project this is clear. But what if there are multiple scenes inside a solo-frame (like A1, A2, A3…) and one B scene outside of it. There is not a possibility of loopback retrigger of the correct running A scene everytime?

[GGGss]

No, because we lack tracking functionality. You cannot know which function did run right before you did something else, and when this something else stops, reverts back to the previous running function.

But wait, what if you disable the solo frame? I should try this once. Maybe you do?
This would mean that 'B' would 1st disable the solo frame, run its function and then re-enables the solo frame... Hmm how do we know when 'B' ends and run the enable frame?
[edit] This will break the question for fading in/out of course [/edit]

[giacomo]

I've reported the bug.

[Sidlomydlo]

This would mean that 'B' would 1st disable the solo frame, run its function and then re-enables the solo frame... Hmm how do we know when 'B' ends and run the enable frame?
[edit] This will break the question for fading in/out of course [/edit]

I have tried this one in several variations (turning the solo frame off before/after switiching to the B scene, re-enable it before/after switching the B scene off)... Seems to me like it does not make any difference. Position still snaps to the A scene, which remains active even when solo frame is turned off.

I've reported the bug.

I have done so few days back, but maybe in a wrong way (in Virtual Console section). My first bug report and no response from Massimo so far. Hope you will be more lucky and Massimo can somehow manage that.

Thanks!

[Sidlomydlo]

I've reported the bug.

Hi Giacomo,

any news about this? My bug report is still without reply.

Thanks!

[giacomo]

Hi Sidlomydlo and Fredjie,
I've I tried to ask for an explanation few days ago, it's important to know what are the plans about ltp handling and consequently the rules to consider for new projects.
http://qlcplus.org/forum/viewtopic.php?t=16181

note for Fredjie:
I've read again your post and I guess I understand your point of view: you're a GMA user "used" to be in tracking mode, isn't it?
I've used for 10 years another software that by default it doesn't track anything, and it has always respected the rule we're speaking here.
I believe you're making a bit too difficult the handling of ltp channels, the logic is simple because there is always only one ltp parameter, the latest! ;)
Indeed, in the example when you release one function the position changes so the software is aware of it, but it doesn't consider the fade-out time, it would be interesting to know if it's by design or a bug.

[GGGss]

When you report it, forget about the colors because in the fixture personality they're meant to fade, I've added the output to your cues to watch them in the 3D view.
The issue is the movement - and probably all the ltp channels - because it doesn't follow the same rule.
If we're "lucky", this is related to this issue where the EFX works only for fade-in times:
viewtopic.php?f=35&t=15940

Gobo and colorwheel are ltp also, but those you don't want to fade I guess... Use these to verify the engine logic.

[giacomo]

And I agree with you, in the example uploaded I haven't chosen to fade the movement (there is a setting in fixture groups to fade the movement) and nevertheless the software it's fading only the time-in.
There are many ltp parameters that are meant to fade, like iris, zoom, focus, strobe, effects... we're speaking about these parameters here, you're mixing different questions because one thing is the ltp logic, another it's a parameter that follows value steps (fade-in/out time = 0).
If you've found that the gobos wheel fades, please report it or make a feature request.
Here it's why we should have/know a consistent rule to apply, otherwise it's a mess if the behavior depends upon the VC widget.

[GGGss]

If you've found that the gobos wheel fades, please report it or make a feature request.
Here it's why we should have/know a consistent rule to apply, otherwise it's a mess if the behavior depends upon the VC widget.

We are talking parallel to each other... but we talk about the same issue - fade-out on LTP channels.
* I don't let gobos fade for one,
Two, if you want, you can let the gobowheel fade from one to the other... simply set a fade-time - I don't consider this as a bug nor a feature - if you want this to happen, it can do so.
[on the big consoles, there is a setting in the fixture profile where you set the 'snap' option on and no fade-times are possible by the engine - again: to your likes]