Please Please

While the behavior of grabbing values into programmer with please-please may seem trivial for a scenario where e.g. a dimmervalue is stored in the cue at 90%, limited by a master of 50%, resulting in the output of 45%.

-> put the outputvalue of 45% into programmer -> output stays at 45%

Imagine a scenario where the dimmer is at the preset "Full", limited by the master at 50%

-> what value to put into the programmer

-> what to output when this value is in programmer

-> what output when this is stored somewhere else and outputted.

is there at all, or some points on this route still a reference to the preset "Full" ?

To add more complexity:

- maybe the output value is affected by a transition between cues, possibly partly referencing multiple presets

- maybe the output value is a sum of an absolute value from one sequence and relative values from other sequences

The scenarios may be different for each attribute of the fixtures of your current selection,

- and several scenarios does not have one indisputable desired outcome.

- grab output and possibly loose reference to e.g. presets or multipart absolute/relative combinations, or

- grab content and keep references, but loose scaling applied to the originating source, and possibly affect output.

Should decisions be made by the console based on fixed set of rules and priorities, by user-configuration, by syntax variants or by popup-dialogs?

The previous generations of MA-consoles, tried to address some of these challenges, with a fixed set of rules, however still not able to cope with every scenario, and predict what the user needed/wanted.

In my personal opinion, the desired outcome and priorities highly depends on the reason for why the user performed the action.

If you pressed please-please to activate for a store-remove, - references to presets is irrelevant, so you don't want to affect output.

If you pressed please-please to store the output, keeping reference to preset could be more relevant than the master accidentally being at 99% instead of 100%, but probably not if the master is at 80% instead of 100%.

Hopefully the next iterations of the gma3 software will allow for better automatic compromises between respecting playback-scaling of originating sources versus preservation of references,

- or for a more user-definable approach and prioritizing of these challenges.

I totally agree than not many (if any) users would want values that jumps.

The current behavior certainly restrict useful workflow scenarios, and needs to be improved.

Unfortunately there are no shortcuts. Bringing your sequence value into the programmer with respect to the scaling, will only get you half there in terms of jumping values:

lets assume that we could easily get the current output (cue-content with respect of the master scaling applied during playback) into programmer.

what would happen when you Store-merge or update that value back into the playback ?

from my previous example, content at 90%, limited by a master of 50%, resulting in the output of 45%.

-> put the outputvalue of 45% into programmer -> output stays at 45%

then adjust your value in programmer from 45% up to 60%, and store/update back to the playback.

To achieve what the user is trying to do, the programmer value of 60% cannot simply be put into the cue, as it would then scale to 30% output by its Master-scale that is residing at 50%

To output 60%, the actual content-value needs to be 120%, (beyond its normal range)

--

Until these complex content conversion processes are implemented, I would recommend to try to avoid combining Master playback scaling, with individual live content adjustments needs.

e.g.

If you are creating a typical theatrical cuelist, don't use the Master/scaling function on that sequence.

- without the Master-scaling, activation, edit and update should work as expected.

For a typical busking/submaster scenario, where live Master-scaling is needed, consider to either:

- use the sequence Master scaling functionality, and be prepared that individual edits of content needs to be performed Blind or Unscaled

- use groupmaster functionality for live Master-scaling, instead of scaling the playbacksource.

When the scaling is done on a fixturelevel rather than on the content source, moving the value between sources (sequence and programmer) is no issue.