Cue Only Timing is changing

[quote=robbie_bruce;43856]change it to use the "next" cue's longest fade in time instead. This should work for most users


if you're taking requests, i'd propose using instead the "next" cue's totalTimeOut. this allows us:

a way to explicitly set a single out time that differs from the longest fade in time, if desired.
what i think is an expected crossfade over the duration of a cue, which might have all 0 up's but takes # seconds due to delays

I do like the idea of using out times in this particular case because it makes perfect sense. However I am not sure it is intuitive as out times usually only have value when intensity is going down.

Let me throw this out since we on the subject and it directly relates to cue only lists. In the not too distant future, we will build in timing rules for things such as merge in the case there is not an existing value rather than just tossing in the default we make some sort of educated guess.

These rules could be also be applicable to how we fade out the existing cue in a cue only list.

For example, using the longest fade time of a particular type.. Second order being a type and kind.. However, it may be unpredictable and requires perhaps too much thought to know what you are going to get in this case..

In the merge example it may cover 90% of the cases which would greatly increase the likelyhood that you don't have to do a merge then follow it up with setting the timing which I agree is a big pain in the ass.

I think out time does give the most flexibility but it does present yet one more thing to consider when merging into a cue only list..

Just something else to consider when working with Cue Only lists..

-Robbie

This doesn't seem to fit in my brain...you guys have to enlighten me a bit more.

What is going wrong if the fade times in Cue Only are the same as they would be in tracking list? Only the target values where we are fading to will change.

I also have a question for all, why we have Cue Only option in lists? Why people use it?
For me it's to simulate preset style console and lists. So, I kind of expect the timing to work the way it works in preset consoles. I must admit I rarely use it and mostly it's used for making chases.
I would like to know what are the situations when release time in Cue Only lists is a good choice.

[quote=robbie_bruce;43873]I do like the idea of using out times in this particular case because it makes perfect sense. However I am not sure it is intuitive as out times usually only have value when intensity is going down.

I haven't used in/out timing much, cause the same result can be done with individual timing (value going down has it's own time). Using / has been just a quick way to makes this faster for a bunch of dimmers.

So, what I expect in Cue Only, is intensities going down to follow the out time or individual time.

After much deliberation, we have decided using the next cue's "out" time does provide the most flexibility. However, we are very concerned about changing existing shows. Currently, there is not a way through syntax to change just out times.

Time /x doesn't work and will need to be addressed as well.

I must say, that most of the critics about Cue Only timing I have received, come from the programmers working in theater, musicals and opera. The reason is, like I mentioned before, that they also expect Cue Only to be the way to simulate preset style console. Sometimes it is easy way to work with list that contain only intensities and creating chases. I think that they (including me) don't use Cue Only much in lists with other parameters.

Time /x sounds great.

I use cue only all the time on TV productions and theater, so this is significant.
Using the next cue out time is a very good way to handle this.
I don't believe that changing this will cause a big problem with existing shows. It is much easier to change the time on a cuelist rather than something else in the programming.

[quote=robbie_bruce;43921]After much deliberation, we have decided using the next cue's "out" time does provide the most flexibility.

do you imply that the out time will be constructed by your educator? i would be glad for that to be the case.


i'd like for my understanding of the actual operations of the educator to be confirmed or corrected:
[INDENT]for each Lkel, Timing will begin as default. upon commencing a merge/release/etc., if Timing has not been explicitly set and still remains as default, Timing will be replaced to satisfaction, specific to the target of the operation.

for each individual FadeDelayPath, each individual Time element will be derived over several iterations of a statistical sampling of a domain or subset of similarly-purposed Time elements already existing in the operation's target.

the iterations are recursive. a return of multiple values will continue; a return of zero values will signal the final sampling set. a return of a single value will be considered deterministic and cause escape.

recursing will be in order of Cue -> Kind -> Function -> Feature -> Type.

how will the value be derived from the final sampling set? the minimum/maximum/average/mean of the entire set? something more complex, such as the average of the two nearest UserNum's?
[/INDENT]


as for path:
[INDENT]i think whether or not path education should be optional is a much more interesting question to pose. as an individual, i would be completely pleased with path education in the case of Linear defaulted features. in the case of non-Linear defaulted Features, i would like education to be applied, but only when the target already contains the same Feature for the same Type.


also, the case of a cue-only release gives me pause. can the scope of this change request be expanded to the playback area? specifically, i think it would be wise to signal that the InterpolationTable is to be applied in reverse.
[/INDENT]