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
Parents
  • 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...
Reply
  • 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...
Children
No Data
Related