Active Memory Does Not Follow Stack

[NPhillips]

When running cues in order, the memory to be affected by edit live does not follow the stack. Example:

 

- [memory][0][GO] everything out

- [GO] memory 1 executes in time

 

- [edit live] "you cannot edit memory zero"

 

 

The correct result should be:

- [memory][0][GO] everything out

- [GO] memory 1 executes in time

 

- [edit live] user now edits memory 1 live

 

 

In this instance, [edit live] will not load the cue in a time; the levels of memory 1 should just appear without delay.

 

If one is live with memory 1 on stage then keys...

 

- [memory][2][edit live] memory 2 will edit live, changing levels in time (as the function currently works)

[K-Nine]

The edit live and edit blind buttons will always refer to the currently selected memory. This is shown by the yellow highlight bar on the screen.

 

On the Memories screen this is the Next memory; therefore pressing edit live or edit blind will edit the Next memory; if you wish to edit the current memory you have to move the cursor there.

 

Pressing the Go button automatically increments the current and next memories, therefore the cursor /memory selection does follow the stack, it's just that the Edit buttons refer to the Next memory rather than the Current memory.

 

To ensure that the red cursor also follows the Next memory you need to have the Memories screen in Follow mode (F7 toggles stay/follow).

 

When you select a memory and press Edit Live, the outputs are deliberately faded up in a nominal time (approx. 1 second) as this is what was asked for - originally they snapped immediately to their programmed levels and this was a cause of concern for some users :shock:

[NPhillips]

OK, I really need to have the selected memory follow what is live on stage, not what is coming next. In a tech, I will start modifying the cue I am looking at.... the operator is going to want to hit channel and go from there.

 

I think this also means that the channel display needs to have the functionality of edit live to save steps and confusion about which mode one is bring up/chaning channels in.

 

If one makes changes to memory 1 in the channel display, realizes they are not in "edit live" and then has to be in "edit live" to make a change and update, those changes will have to be recreated/entered as switching to edit live drops the channel level changes from the CDW. Perhaps this would be fixed with captured channels, or opening the architecture ... what is the necessity to have edit live and CDW separate??

[NPhillips]

In techs this has proven to be a big problem... in order to modify the memory on stage in memory follow on the memories screen, I have to arrow up, and then key edit live. Modifications are made, saved, the window closes, then one has to arrow down or double go.

 

I think the active memory on stage should be the active memory going to be edited.

[spencer]

I find it frustrating that the next memory to go is the same as the next memory to edit. When a show is live or often during rehearsal I want to go and work on a memory later in the stack, because this moves the next memory on the playback I can't carry on editing and press go, I am sure this kind of half a brain on the rehearsal of the first act half on plotting the second act goes on all the time. In a similair product I use for tv playback there is a right click edit that doesnt select the event as next, perhaps this would work so I right click a line and it opens the CDW for editing blind and leaves the next memory marker where it is. I think most of the confusion in what the board does is because of this dual function of the next highlight.

[K-Nine]

The comments from Mr Phillips and Spencer are perfectly valid and reflect the way that they think the desk should operate.

 

However, we have to be very careful if we decide to change one of the fundamental ways that the Memories Screen and CDW interact with regards to the current, next and selected memory identification, disaplay and editing modes etc.

 

This is one of the areas where having a single mode of operation (cf older desks which had separate program and run modes) can cause confusion - especially if you make assumptions and don't read the manual :evil:

 

I think that we need to review how the current, next and selected memories are displayed and interact on the Memories screen.

 

Spencer's comment re the yellow bar indicating both the Next memory and selected memory could well be the important factor for discussion here.

 

As far as the playback is concerned, it was decided early on in the design process that the current and next memories needed to be displayed on the Memories screen.

 

Similarly, when selecting a memory to program, edit, copy, transfer, delete etc., the selected memory needs to be highlighted.

 

The decision to make the 'selected' and 'next' memories the same was made very early on, but this has caused some confusion :?

 

Having the 'selected' memory follow the 'current' memory rather than the 'next'memory as at present, would obviously suit Mr Phillips, but presumably a user would also require the ability to select any memory for programming, editing, transferring etc. In this case the 'selected' and 'current' memory numbers would be different. Do they remain different and how do we then decide what say Edit Live or Edit Blind operate on ?

 

This sort of functionality is never as straighforward as it might first appear, but hopefully with your help we will get it working the way the majority of users want or expect, as you can never please all of the people all of the time

[NPhillips]

Having a command line all the time would solve this...

 

I am running a technical rehearsal and [GO] on cue 12. We are now in cue 12. When I want to modify channels 1-4 @ 50, the operator simply keys [edit live][1]thru][4][@][50][save][enter]. Done.

 

So I am sitting in cue 12 and now want to modify cue 100 live. The operator keys [memory][1][0][0][edit live]. Memory 100 is live in edit live while memory 12 remains in the fader. Saving or simply closing edit live memory 100 puts me back in memory 12 on stage since it remained in the fader. Memory 13 (or the next memory from 12) will be the next to play in the fader unless the operator were to key: [memory][1][0][0][enter]. That then selects memory 100 (as it had done before for edit live), making it next in the stack.

 

The problem of updating changes in other memories can be solved with "update in". Memory 12 is active in the playback, I decide I want channels 1-4 @50 - this is where the command line comes in - where now I should be able to say, "update in memory 12 and memory 100 thru 400 enter"... see?

 

This principal should work in both cue only and tracking modes of operation ... keeping in mind that cue only requires the operator to define track or not and tracking is the opposite, the operator defines cue only or not. Although, in the example above, say we were in tracking mode, would still be true as the update would be saved in those memories regardless of blocks or level changes. To say "update in memory 12 and memory 100 enter", while in tracking mode, would update 12 and 100 to track until change. "update in memory 12 cue only and memory 100 enter", would only affect the change in cue 12, but would track forward until change from memory 100.