New release still not dealing with fade times

So, here we go again. We have anew release but everytime I update or record/merge a cue or string of cues in a cuelist the cuelist window time column freaks out and displays seemingly randon numbers, I've been here before with this issue and gotten no valuable response. Maybe Brad has some new news?

jb
  • You might want to provide a little more information.

    I have been using the III for quite a long time and have not seen anything like you are describing.

    Can you give some more details so people can chime in if they are having the same problems?
  • John,

    When you update a cue it will reassert itself and you will see this in the wait column of the cue that is currently playing on stage. Is this what you are seeing? This is not a random display, but actually a display of how it is asserting your update. If you are referring to something different, please send me a better description as John says.

    thanks,
  • Hey Jon and Brad,

    Let me see if i can make this issue clear in words. Let's assume i have a cuelist with cues 1 through 10 already written and each has a global fade time which I have assigned and is viewable in the fade column in the cuelist window. (I work mostly in a theater environment, if that helps) I throw some stuff in the programmer and [record] [merge] [cue] [2] [>] [6] and turn off track forward for this action only. The times, as viewed in the cuelist window, now have what seem to be some random additions that were not there before i did the record merge function. These new times are separated by commas, as if i had gone into the time window and changed attribute or fixture times within each particular cue, which, of course, i have not. So now, if i run cue 2, and i decide i want to add 1 second to the fade time, i look a the fade column and see "2,4,3" (let's assume for the sake of this demonstration that the original fade time i designated was 4) I don't remember what the global fade time i assigned was so i can't just add 1 second. I have to open the time window for the cue to figure it out which takes way too much valuble programming time away from me when working on the fly with 100 people waiting for me to say "okay, we can go on."

    Please help me!!! :dunno:

    Thanks a bunch and i hope this is more clear than my previous post.
  • Hmm... I remember there has been a discussion about time tracking. Merge and update with forward off causes some kind of a cue only operation to time also. However, the actual result seems to be just zero seconds in fade column and if I open the cue there's no zero seconds... When a merge to multiple cues is done this happens to all cues, zero second time is added to all "cue only" cues... for me this seems to be a bug... at least when I'm adding new information to cue.
  • I'm not at the desk right now but I have run into the same problem. I also work in theatre and end up having to update Q's cue only (forward tracking off) and it seems that fade times get carried over into the next Q for the fixtures that you have edited instead of taking the Q's fade time. I have also seemed to end up with random 0s fade times for certain fixtures in Q's through using update.

    I can try and inverstigate when I'm at the desk tomorrow or Saturday so that I can try and shead some more light on this if it would be of some help.
  • Andy,

    I have tried to find some rhyme or reason to the way the Hog 3 adds fade times to modified cues and have so far been unsuccessful. If you can figure it out, i'd love to hear about it. We seem to be talking about the exact same thing and now I know three designer/operators who have found the same issue with the software. It's really a big obstacle in the theater world when trying to make quick global changes to cue fade times during tech and dress rehearsals. Thanks for your imput. I hope we can figure this out and get it fixed in the future.

    John B.
  • John,

    One reason is the forward off (cue only) operation, like I said, when adding new information to cue. It adds zero seconds to next cue. Bad thing in all this is, that the fixture or channel you added to the cue fades out in zero seconds in the next cue, but if you open the cue, the fade time there is the default time. This is really something that should be fixed, cause this would drive me also nuts when programming (I also do mostly programming in theatre).

    I also noticed that when using merge timing is masked by default, so when I modify a channel + timing and merge that, timing is not recorded. I suggest, the correct masking should be show like when pressing update.

    The ugliest part in this timing mess is, there's also something really wrong with timing tracking. Pretty easily, when playing with timing I managed to be in situation, where I had a cue, which had a timing of 10 seconds in a channel. The source of tracked information was cue 1 and I hadn't changed the timing of that channel. But in cue 5, I had a tracked value of 10 seconds after a tracked of 4 seconds (which was the default time) in cue 4. I think the reason of this, is a forward off operation with merge and use timing on of another channel.
    So, when I added a value with timing and using forward off it modified the tracked timing values of other channels in the next cue. They can be seen when opening the cue, but they are not shown in the cuelist time column. I just wonder, how I can have different value of timing and it is shown as tracked in the cue editor window.
    And this gets nastier. Now, because I have those "ghost" timing values in a cue, next time, when I do a merge with forward off operation in a cue before those values, they come alive.

    I think this is a major bug or someone should have a pretty good explanation why timing works this way, cause I don't get it.

    I edited the text a bit to make it a bit more clear...I hope so...
  • Thanks for the clear posts Sami and John. We will investigate a bit further.. I think that the key here is with turning track forwards off, but until we really test it futher I can not comment fully. I will look at this asap and let you know the results early next week.

    thanks again to all,
  • I can send you the showfile I did the testing, when I get back to my comp (later today). Though, reproing this is quite easy.

    A little summary of problems.

    1) How forward off affects timing with merge (using default time), might happen also with update.
    2) Differences in cue column and cue editor
    3) Merge and masking. With update this is obvious cause it is shown in the toolbar, but with merge it isn't and timing is masked.
    4) When I inspected this more, I noticed when I merge a new channel to cue with new timing all channels that are tracked more than one cue get the value also...it is shown only in cue editor. This causes a problem when something is merged to these channels with forward off to previous cue.
  • One more thing to check.
    I noticed, when using merge with backtrack timing is not recorded at all (use timing was on)


    EDIT:
    Also, because now update and merge work a bit different way when using forward off and backward on, it can be seen also in timing.
    Though, now merge doesn't record timing at all when using backward, but update does when use time is on. I have had a little discussion about the differences of update and merge with Chris. So, he knows about the issue when using combination of forward off and backward on.
  • All,

    I have logged some bugs related to this thread today and will be logging more as I continue to reproduce these issues. Thanks for the clear descriptions. Hopefully we can get these sorted out soon. I will post more details as I have them...
  • As a theatre programmer I'm interested, what is the timeline for fixing this?

    Also is there any plans to change the way Cue Only option works for cuelists? Now the parameters fade out using release time, which is very different way compared to Hog2 maintain state off. Or are you gonna add Hog2 style maintain state button?
    Also what is the current plan for fixing the difference in backward tracking when using merge or update?
  • Sami,

    Version 2.5.0 has just been released and it contains a fix for the main problem in this thread:
    Bug#11662 Merging with track forwards off causes incorrect cue times to display in cuelist window
  • Thanks Brad

    I hope the other problems will be fixed pretty soon also.

    1) Backward tracking difference in update and merge
    2) Cuelist Cue only option timing difference compared to Hog2 maintain state
Related