Please Please

  • Tapping Please Please does not seem to respect the fader position when it grabs values from a sequence.

    That mean the output change. I assume this is not how it's meant to be?

    (Manual says 'current values')

  • 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.

  • Until now I've actually thought this was trivial :)


    One thing I want to do is get the value seen in fixture sheet into the programmer.

    (For instance if I want to adjust a value live on stage and make sure I don't get a jump.)


    I've tried On + touch Dim and I've tried to turn the encoder. Both jumps to stored value regardless of fader position.

    (Do users really want that to happen when you turn the encoder too??)


    What works is to press the encoder and then press please in the dialog box.

    This is ok, but are there other ways? Preferably one that could be used in a macro.

    Edited 3 times, last by Ringen ().

  • 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.

  • Lot's of scenarios here and I have given it some thought.


    What if the programmer was switchable Pre / Post sequence masters ? (Called Fader from here)


    Values would always be grabbed Pre Fader and adjusted Pre Fader. (As it currently is)

    Only the viewing/output of values would be Post Fader(s) ! (Like it currently is with Group Masters)


    In "Pre Fader Mode" it would work exactly like today.

    In "Post Fader Mode" all jumps would be gone.

    Scaling issues would disappear.

    Fader could even be adjusted after the grab.

    Reference to Presets could be kept, and Presets could be updated as usual.



    With 'Grabbed' I mean 'Please Please', On, Edit Cue or similar.

    And if we do need the actual current value we can still press the encoder and get that.

    Last method could preferably ignore the Post Fader setting, but one could also switch to Pre Fader of course.



    What do you all think?

    I'm sure there are issues I have not considered, but I think this would solve it for me.