Options
Related

[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
Parents
  • 0
    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
Reply
  • 0
    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
Children
No Data

www.etcconnect.com