Arm/ disarm

[Jeremy Lee]

Something that's gotten me a few times but I've forgotten to report it. Disarm a cue in a playlist. Then disarm the playlist itself. Rearm the playlist. The cue you had originally disarmed is now armed.

Jeremy Lee
- A thumb is a terrible speller. Please forgive my trespasses.

[Chris Ashworth]

On Jun 12, 2012, at 10:41 PM, Jeremy Lee wrote:

> Something that's gotten me a few times but I've forgotten to report it. Disarm a cue in a playlist. Then disarm the playlist itself. Rearm the playlist. The cue you had originally disarmed is now armed.

Do you reckon this to be a bug? (I do not.)

-C

[Jeremy Lee]

Yes I do! If I disarm a cue list or group cue, and then rearm it, it should return to its previous state.

Many times I'll leave a cue disabled in a group because we liked it yesterday, don't like it today, but might like it tomorrow. I'll generally clean these out around opening. If I subsequently disable a group with some things disabled and others enabled in it but it comes back tomorrow, it should restore itself.

I find I run into this quite frequently, and have to remember what to enable and disable...

Jeremy Lee
- A thumb is a terrible speller. Please forgive my trespasses.

> --
> Change your preferences or unsubscribe here:
> http://groups.google.com/group/qlab
>
> Follow Figure 53 on Twitter: http://twitter.com/Figure53

[Chris Ashworth]

Hm, I can see that angle on it. But the behavior I expect is:

• disarm a group and it disarms all the cues in the group

• arm a group and it arms all the cues in the group

This is sort of the point of groups; an action on the group is an action on all the things in the group.

[Mike P]

Hmmmm... Cue lists have the same behavior for Arm/Disarm. I bet it's one of those features that will cause as much trouble if you change it than leaving it alone. Who know's who is depending on that behavior without even knowing it.

In programming, I could see the need for a construct that would allow you to disarm a section of code and then re-arm it to it's original state - like commenting out code to get it out of the way while you debug something else. Something for the future?

Meanwhile, could you create an 'unlike' script to disarm the cue in question and change it's color for easier identification? Then make a 'relike' script to arm and change it back?


Mike Post
(601) 307-8657
mdp...@mac.com
http://mdpostdesign.com

[Jeremy Lee]

From my angle, a group is a series of separate events. If it wanted to disable all elements of a group, I'd select all and run Rich's AppleScript. I suppose if the group was collapsed I might expect it to act on all internal parts, but not as a macro when it's expanded.

Almost every show I have an AppleScript Cue list that I turn off during previews so the operator has no chance of doing something funny. Then at tech the next day I re-enable it for myself. If I've disabled any of the AppleScript cues, they magically come back to life.

Jeremy Lee
- A thumb is a terrible speller. Please forgive my trespasses.

[Jeremy Lee]

And, I would guess, by design if a group cue is disabled, it would make it so all internal cues would not fire unless they were triggered individually by midi or something.

I'd just be super happy if the logic went that disabling a cue list or group caused all internal elements to be temporarily disabled, but they didn't forget their previous status.

Jeremy Lee
- A thumb is a terrible speller. Please forgive my trespasses.

[Chris Ashworth]

On Jun 13, 2012, at 10:27 AM, Mike P wrote:
> like commenting out code to get it out of the way while you debug something else.

That's a nice way of thinking about it. Hm.

-C

[ra byn (robin)]

A "freeze in place cue"...(2) states. What is it when unfrozen (with any
number of cues armed & disarmed) & then frozen. Maybe even with a lock.

*

[Andy Dolph]

I like the idea of being able to "disable" a cue vs "disarm" it.  The idea being that disarm is the curent functionality, designed to operate programmatically as a part of normal operations whereas NOTHING can make a disabled cue active other then manually reenabling it - much like commenting out code.

Andy

[Dave Tosti-Lane]

Plus one for this


On Jun 13, 2012, at 8:44 AM, "Andy Dolph" <acd...@gmail.com<mailto:acd...@gmail.com>> wrote:

[Chris Ashworth]

To me this seems like to introduce confusion:

"Which do I do? Disable or disarm? huh? what's the difference?"

-C

[Clay Benning]

Maybe we need a hidden/less obvious function for disable. Like option-click on the disable checkbox and the cue is "disabled" instead of "disarmed".

A change in the style of the disabled hash (like a red line through it) could visually indicate that the cue is disabled instead of disarmed.

I also (currently) find it useful to leave things disarmed during tech to preserve options.

Clay

[Dave Tosti-Lane]

Or perhaps just what amounts to recall-safe for cues. You could even make it a preference, or just a button on the overall window that would light red when activated. Engage recall safe and all these behaviors would be remembered on a nested level.
So, you could disarm/arm individual cues within a group, and that would be remembered if you disarmed/armed the group. Likewise, groups and cues within a list would remember their state when you disarmed/armed the list.
But, you could leave the recall safe switch off if you wanted the original behavior.
As with consoles, you could perhaps have a preference setting to determine what parameters were affected. (but unlike Yamaha, you could make it actually work)

Dave Tosti-Lane

[Mike P]

>
> Maybe we need a hidden/less obvious function for disable. Like option-click on the disable checkbox and the cue is "disabled" instead of "disarmed".

I think making it too obscure kind of defeats the purpose but I like the idea of making it an extension. I suspect many people are looking to disable when they disarm. The (proposed) differences seem to be:

Arm/Disarm can be done as part of the cue list flow - it's programmable. Changing the state of the container (group or cue list) changes the state for the cue.

Disabling a cue shouldn't be something that can be programmed, but is set for a cue manually. Cues that are disabled must be re-enabled manually per cue regardless of the status of the container.


Maybe this change to the Arm/Disarm control to a drop down instead of the check box? Kind of like the Continue - 3 options.

Armed: Execute normally
Disarmed: Do not execute, update with the container
Disabled: Do not execute, ignore the state of the container.

The Arm/Disarm cues could operate to the second level only. In order to enable/disable it, it takes manual action.

This doesn't really address Chris' confusion concerns though. Hmm....

Mike Post
(601) 307-8657
mdp...@mac.com
http://mdpostdesign.com

On Jun 13, 2012, at 12:21 PM, Clay Benning wrote:

> A change in the style of the disabled hash (like a red line through it) could visually indicate that the cue is disabled instead of disarmed.
>
> I also (currently) find it useful to leave things disarmed during tech to preserve options.
>
> Clay
>
> On Jun 13, 2012, at 11:54 AM, Chris Ashworth <ch...@figure53.com> wrote:
>
>> To me this seems like to introduce confusion:
>>
>> "Which do I do? Disable or disarm? huh? what's the difference?"
>>
>> -C
>>
>

[Jeremy Lee]

This is like in ProTools where there's a difference between muting a track and disabling it. Me likey.

Jeremy Lee

- A thumb is a terrible speller. Please forgive my trespasses.

--

[Dave "luckydave" Memory]

To address the options issue, Jeremy, leaving aside Disarm/Disable: How about a group cue set to fire the first child and go to the next cue? Then, you can bury options under the first cue in the group, and pull the one you want to actually use at any given time to the top. No arming and disarming, no state changes, and no loading of extraneous cues, since disarmed cues will still load in a sequence. That could affect programming with auto-follow timing a bit, but I feel like that could be worked around. Maybe it's not the solution for your workflow, but it's an idea.

-- 

luck...@figure53.com

[dan howarth]

On Thu, Jun 14, 2012 at 10:11 AM, Dave "luckydave" Memory <luck...@figure53.com> wrote:

To address the options issue, Jeremy, leaving aside Disarm/Disable: How about a group cue set to fire the first child and go to the next cue? Then, you can bury options under the first cue in the group, and pull the one you want to actually use at any given time to the top. No arming and disarming, no state changes, and no loading of extraneous cues, since disarmed cues will still load in a sequence. That could affect programming with auto-follow timing a bit, but I feel like that could be worked around. Maybe it's not the solution for your workflow, but it's an idea.

yes that's an idea --- a very good method to approaching this sort of thing -- 

if i were doing this sort of thing (using qlab to preview various tracks for a production situation) -- i would STILL want to DISABLE the "non-choice" tracks in the remainder of the "group cue set to fire the first child and go to the next cue" group ... so that when i / non-me-people LOOK at the group we would see ... ONE TRACK that is armed and ready .. and yes seeing the "others" would be great too ... as long as they are visually differentiated so that there's .. no question about which track is the real playback track .. of course at some point i would probably make a new playlist using the chosen tracks .... and we'd use that for tech-dress situations and on into the shows .... depends on how much time is available. 

i say all this because i know from experiences that non-computer folks won't always trust the process, the system --- inevitably they will say "well what are those other tracks doing in there" - "are you sure they won't play?" and on and on ........ if the other tracks are disabled, and the disabling function gives more or less the same effect as disarming a track ... it's VISUALLY apparent that there's only -one track- that has been selected, chosen, appropriated, defined. ya ya ya.  

this point about group mechanics (thanks lucky_dave) reminds me of an upcoming show that i've got on my radar -- the fire RANDOM child thing -- is going to be very very helpful.  

[Maik Waschfeld]

Second on this!

regards...

...Maik

(PGP-key on request)

Direkte Emails auf's iPhone: <mailto:Maik.Wa...@vodafone.de>

Phone: +49-711-336 18 83 • iPhone: +49-172-714 50 36

Fax'n'Phone: +49-1805-060 334 021 12

<http://www.maik-waschfeld.de/>

...the manual said: Win XP/Vista/7 or better, so I used Mac OS X.

[Jeremy Lee]

I'm almost onboard with this, but I also think that Enabled/ Disabled should be available via AppleScript. There could be a situation in which you want to Disable a batch of cues for an entire show (understudies/ double cast roles, etc) but want to Arm/ Disarm cues as part of a complex loop or other sequence.

Is this too much Left Brain activity for tonight? Maybe...

--
Jeremy Lee
Sound Designer, NYC - USA 829
http://www.jjlee.com

[Jeremy Lee]

That's certainly an idea, but it's REALLY nice to be able to look at a group/ cue sequence and see that certain cues won't play since they're striped out/ disabled.

--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

[Andy Dolph]

I tend to be in favor of making EVERYTHING available via AppleScript - you can't trigger it by mistake, but the capability is there if you need it....