[Help] Merging Only Time Parameters

I noticed this a while ago, but forgot to post on it. I'm not sure if it's operator error, or something else. Either way it would help if someone could check this and report back.

I am unable to merge or update only time parameters into existing cues via the programmer only. If I use the existing cue editor in "Edit" mode, then I am able to update time changes.

Here is a reproduction...

1. Patch a test show with 10 movers

2. Grab all 10 and set I,P,C and B in the programmer and record to 1/1

3. In the programmer only... change only the Fade and Delay times to something else and try to merge to 1/1.

4. Clear the programmer and then check the timing for 1/1. The time values did not change.

5. Try the same process with the Update function and it won't update either.

6. Now... Clear the programmer and "View Cue" 1/1. Enter edit mode in the Cue Editor. Select 1 thru 10... and change the time values via the syntax or by manually editing the fields in the editor. Now exit the edit mode of the cue editor and allow it to update.

7. Check the cue contents and you will see that the time values have been updated succsesfully.

I have noticed that the only way to change time in an existing Cue is to update via the cue editor or just record the entire cue over the previous cue.

Could someone kindly check this and let me know if I might be doing something wrong?

Thanks

JB
  • JB you dont do anything wrong. I just had a chat with Chris and Robbie about that issue.
    Maybe they can it explain here again.
    It has something to do how times are handled, default timings and so on.
    Thats why it works when editing but not when just merging.
    I will see if I can find the reason for that, after they explained it to me, I understood the reasons
  • Yes...

    A quote from Robbie Bruce:

    "The programmer is defaulted to not USE TIMING so avoid us having to guess that the user wants to update everything based on potential default timing. We would get similar complaints but from the opposite view point..

    The idea being you open the programmer and change a parameter (then we set timing to default automatically) and that may not be what you want when you update the cue.

    Opening a cue editor you have the time programmed and it is assumed you opened the cue to make the change and we assume USE T

    Programmer does not assume USE T.

    ....

    The basic problem is that within the programmer we can’t tell what has been programmed and what has been set automatically (such as timing) to differentiate the two.

    However, I will go ahead create a request to track whether a value has been set to defaults are actually programmed"

    So like you said. A limit to the code at the moment. It took me some seconds to understand, but when you think about it is correct
  • I had to read the above post about 10 times to wrap my head around it, but here goes..

    The idea is that... Whenever you use the programmer to enter a value, the programmer automatically enters a default timing value for that parameter, which is seen by the H4 code as a recent user change, or a touched value and then would always need to write that default timing over and over again regardless of the fact that the timing value might never have changed. So, the developers decided to disable timing merges/updates from the programmer to avoid the unecessary and redundant writing of the same "Time" data when updating or merging cues from the programmer in cues where only parameter values changed without a timing change for those parameters?

    Is that correct?

    If so... it seems like it was a software design decision to ignore timing updates from the programmer to allow the merges/updates from the programmer to complete the operation quicker and for a snappier and faster user experience on the H4 desk when updating and merging from the programmer. I guess this would make sense, since for every single parameter in the H4 system exists an additional 4 timing parameters that needs to be written when saved.

    The only small issue I have with the idea, is that it throws a wrench into the programming workflow. It forces the user to interupt the use of the "Programmer" Window to complete the building of a cue from start to finish. So you can start in the programmer, but then you need to clear the programmer, which in some cases you may lose your grouping, selection order and fanned settings.. Then you need to open the Cue editor, enter edit mode, re select fixtures, possibly reset grouping and fan setting then make your changes and update timing. Then you end up having to use the programmer to build the next cue.

    If one could stay in the programmer through the entire process of cue writing, parameter tweaking, fade checking, timing tweaking, then we would not lose the selection, grouping or fanning when switching from the programmer to the cue editor and then back again to polish off a cue.

    Take my request with a grain of salt though... as it seems like I might be the only one that finds this particular path a hair bumpy.. ;)

    Thanks guys.

    JB
  • Maybe giving the end user both options. Default the programmer to ignore timing merges and updates if the Kind Mask "Time" is unselected. Then, if the user updates or merges a timing change via the programmer with the Kind Mask "Time" selected then it will force the programmer to recognize time as a valid change and re write the timing values durring the merge/update.

    JB
  • I agree it would be nice to be able to record only timing from programmer and I kind of don't understand why it cannot be that way.

    But to my understanding the reason is that time is bound to parameter value... that's why you cannot have pure timing palettes.

    The default of NOT to USE T is good... it would really mess up things if default timing would be recorded when just updating values (like we are doing most of the time)

    So Jeff if you want to update times, just grab the values too and USE TIME.

    But while I was checking this I noticed there seems to be a bug in Merge.

    The mask shows timing is recorded but that is not happening (when no masks is highlighted, everything is recorded)
    If you choose IPCBET and Merge. Timing is recorded.

    Things are quite strange if you use Record with merge option. The mask of record is shown. Timing is recorded if you just record, insert or replace, but when merge is used no timing is recorded unless you select the masks (IPCBET)
  • [QUOTE=Buzz313th;67300]
    The only small issue I have with the idea, is that it throws a wrench into the programming workflow. It forces the user to interupt the use of the "Programmer" Window to complete the building of a cue from start to finish. So you can start in the programmer, but then you need to clear the programmer, which in some cases you may lose your grouping, selection order and fanned settings.. Then you need to open the Cue editor, enter edit mode, re select fixtures, possibly reset grouping and fan setting then make your changes and update timing. Then you end up having to use the programmer to build the next cue.


    It is only when you edit in the programmer!!!!!
    When you create a full cue including timing I think it works like it should.
    So only if you have just time-parameters (which are kind of "virtual" parameters of a fixture) in the programmer it doesnt update.
  • [QUOTE=srautane;67302]I agree it would be nice to be able to record only timing from programmer and I kind of don't understand why it cannot be that way.

    But to my understanding the reason is that time is bound to parameter value... that's why you cannot have pure timing palettes.

    Thats how I understood as well.

    [QUOTE=srautane;67302]
    The default of NOT to USE T is good... it would really mess up things if default timing would be recorded when just updating values (like we are doing most of the time)

    Yes... and like Robbie mentioned he logged a request so that the console can see if the time hasd come from a default time or programmed or edited via programmer
  • A somekind of workaround is to use Cue # Copy Enter to bring the cue to the programmer with times, adjust and update/merge with time.
  • Sami, that doesn't work. And if you are able to merge changed time pentameters into an existing cue like that... Then please give me a reproduction because I can't get it to work.