Filtering copy

Does this make any sense?

It is possible to use Group # Cue # Copy [enter] to bring fixtures to programmer...
How about bringing only fixtures which have intensity above 0% ?

This idea comes from the use of Live / Group # , which makes selecting fixtures very easy...but is only for fixtures which are really outputting
Parents
  • [quote=teerickson]bellons,
    "Copy this cue into the programmer, but don't overwrite any of the stuff I already have in there."

    And there lies the debate.

    Would that be useful?
    What is the most logical syntax to implement it with?

    The syntax is difficult:
    -When you merge something into a cue, it overwrites. So does it make sense to merge something into the programmer and it does not overwrite? One could say, during merge operations the programmer always has the highest priority - is this philosophy "right" or is "merge" defined different at some other point?
    -copy... I don't know. merge just does make more sence if you combine information from different sources.

    so i like merge to only add new parameters and copy to copy all parameters that are in the cue for currently selected fixtures.

    i.e. cue 1 merge enter
    or "cue merge enter" would merge all parameters from the current cue of the selected master (so you don't have to type the number if the cue is already active)
    and "list merge enter" would merge all information for the selected fixtures up to the current cue of the selected master.
    or doesn't this make sense at all?! it just sound very nice to me right now... :sad:

    now it comes again to the "undo"-bug: a typical use would be to take a group of lamps, select a positions, now merge a cue containing a move and a color-effect, undo the color and merge again from another cue that has the right colors in it. So get undo working like on the hog2 first!

    Jan
Reply
  • [quote=teerickson]bellons,
    "Copy this cue into the programmer, but don't overwrite any of the stuff I already have in there."

    And there lies the debate.

    Would that be useful?
    What is the most logical syntax to implement it with?

    The syntax is difficult:
    -When you merge something into a cue, it overwrites. So does it make sense to merge something into the programmer and it does not overwrite? One could say, during merge operations the programmer always has the highest priority - is this philosophy "right" or is "merge" defined different at some other point?
    -copy... I don't know. merge just does make more sence if you combine information from different sources.

    so i like merge to only add new parameters and copy to copy all parameters that are in the cue for currently selected fixtures.

    i.e. cue 1 merge enter
    or "cue merge enter" would merge all parameters from the current cue of the selected master (so you don't have to type the number if the cue is already active)
    and "list merge enter" would merge all information for the selected fixtures up to the current cue of the selected master.
    or doesn't this make sense at all?! it just sound very nice to me right now... :sad:

    now it comes again to the "undo"-bug: a typical use would be to take a group of lamps, select a positions, now merge a cue containing a move and a color-effect, undo the color and merge again from another cue that has the right colors in it. So get undo working like on the hog2 first!

    Jan
Children
No Data
Related