DISARM CUE

[Vinny Osborne]

What is the point of Disarming a Cue in V3 if the Cue still gets highlighted and you still have to skip over it manually.

Why isn't it ignored or even better removed temporarily from the cue list?

[Sam Kusnetz]

The general point of disarming a cue is to prevent it from "speaking",
but not interfere with any other programming. If the disarmed cue is
part of a cue sequence, for example, disarming it will not have any
effect on the sequence, and auto-continues or auto-follows will work as
before.

If you want to completely pull a cue out of the cue list you could, for
example, make a separate "cue cues" cue list to move it to.

Cheerio
Sam

--
Sam Kusnetz
QLab Field Operative
s...@figure53.com

[Nigel Hogg]

I agree with Vinny. It would be very useful if there was a way for disarmed cues to be skipped and the next armed cue to be highlighted. I don't understand the point of highlighting a cue that is disarmed, and can't think of a reason to fire a disarmed cue. Maybe we could be given the choice?

Nigel

[Joshua Langman]

I disagree. There are plenty of reasons to fire a disarmed cue, mostly having to do with its place within a cue sequence, where totally eliminating the cue would disrupt the flow of the rest of the sequence. Why the desire for disarming a cue to make it behave like it doesn't exist at all? If you want that, I would say delete the cue or move it to a separate cue list.

[Joshua Langman]

Also you need to be able to "highlight" (select) a disarmed cue in order to change any of its parameters like, say, re-arming it.

[Vinny Osborne]

I have no idea what those of you who disagree do for a living, but obviously not in my world.  The reason for a disarm/invisible cue is to temporarily remove a cue for a singe or multiple performance but have it available for other performances without having to have multiple qlab files.  The problem with having multiple qlab files for the same production would be that if you do make a change on the fly, well then you have to replicate those change in your other files.

As regarding keeping your sequence the same, I would love to see a real world example of why that is necessary.  I see many reasons for my request.

[micpool]

I think many of the people that are happy with the way the disarm cue works do similar things to  what you do for a living. It would be helpful to have an example of what it is you are trying to achieve.

If  what you want to do is have alternative versions of cues for understudies etc then the way many  people do this with Q lab is to put all the alternative versions in a fire all group and disarm all versions except the one required for that performance. 

If your skipping a block of cues for a short version then arming and disarming goto cues to skip or include sections is much quicker than changing the arm status of bunches of cues,

Mic

[Daniel Perelstein]

Vinny,

I'm a disagreer, and for your information, what I do for a living is theatrical sound designer.

I use arm and disarm cues all the time, and would be driven crazy if my cue sequence timings were compromised.

Here's an example:

-My QLab sequence handles sound effects, playback music, and controls my sound console (and associated live mics) via MIDI. I'm running a sequence over and over again to get the playback levels right, but actors are on break, so I disarm the MIDI commands so I can continue teching without actors' mics coming live during their break.

-a sequence of music, and in the middle of it is a loud gunshot, timed closely with a large number of other elements. The sequence requires a lot of tech time and repetition, and it's really not necessary to fire the gunshot cue every time, so in order to maintain our sanity, I disarm the gunshot sound cue so I can continue perfecting the timing of the sequence without hearing the loud gunshot every time.

-I've got a dance sequence going, and there's a physical comedy bit that happens elsewhere on stage, accompanied by a sound cue. If the dance music is still playing when the physical bit happens, I need its associated sound cue to occur at a loud volume, whereas if the physical bit happens after the dance music finishes, I need its associated sound cue to play at a lower volume. One way of addressing this (and of course, there are others) are to have the physical-bit-sound-cue twice in the cue stack, at two different levels, and have them armed and disarmed as appropriate based on the timing of the dance music.

Just a few ideas. I do use disarm and arm constantly and have never had a problem with its usage.

If you prefer your usage, all you have to do is remove the cue, or have a GOTO cue to jump past things in your stack (the GOTO could be armed or disarmed as needed). But for my usage, there'd be no way of duplicating it if disarm did what you describe.
Dan

Daniel Perelstein                 

Full-service music and sound for the theater

Musical Direction | Sound Design | Composition | Multi-Instrumentalist
Conducting, Arranging & Orchestrations, Vocal Coaching, Accompanying
www . danielperelstein . com

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

---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nigel Hogg]

I can see both points of view. In Dan's case, yes, the present operation of disarm is essential. I suspect that Vinny works the same way that I do, where it would be useful to have a way of missing out disarmed cues compleately from a cue sequence and simply firing the next cue. I would personally find that easier and more convenient than Mic's solution That is why I suggested there could be a choice of behaviour, to suit everyone.
Nigel

[Daniel Perelstein]

A GOTO cue will skip over cues if that's your goal. If you want cues to be skipped only sometimes, set up the GOTO cues as if you want the skipping behavior, and then set up a series of disarm cues that disarm your GOTOs in the event that you don't want the skipping behavior. 

Programming your arm/disarm of the GOTOs in a separate dcelist that can, itself, be armed or disarmed, would be one simple way of organizing all of this. 

Dan

On Sunday, May 11, 2014, Nigel Hogg <nh...@me.com> wrote:

I can see both points of view. In Dan's case, yes, the present operation of disarm is essential. I suspect that Vinny works the same way that I do, where it would be useful to have a way of missing out disarmed cues compleately from a cue sequence and simply firing the next cue. I would personally find that easier and more convenient than Mic's solution That is why I suggested there could be a choice of behaviour, to suit everyone.
Nigel

[fishmonkey]

i can see both points of view, however as someone who codes quite a lot, i try and avoid GOTOs when possible, because they easily result in messy logic in the flow of things...

To unsubscribe from this group and stop receiving emails from it, send an email to qlab+unsubscribe@googlegroups.com.

[Willo]

I would love it if there were a MUTE/UNMUTE function where the cue would still play for timing and effect but not be heard (i.e. pretty well what there is now, and you could still call it 'Disarm' so no one gets confused)

And then there could be a DISABLE/ENABLE function, which would render the cue invisible to the play head (i.e. it would be automatically ignored and skipped over, having no effect, but remaining in place).

That could save a lot of fiddly subroutines with disarming GOTOs.

Cheers,

Craig

[fishmonkey]

i agree, having both options would be a good thing...

[Christopher Ashworth]

> On May 12, 2014, at 4:40 AM, fishmonkey <fishmo...@gmail.com> wrote:
>
> i agree, having both options would be a good thing...

While I understand that the different behaviors are both useful, I disagree that it is a good idea to create an option for both in the manner suggested.

I do think it's good to sometimes add an option for alternate behaviors, but adding options is a deceptively damaging practice when overused. It's a tricky balance to strike, because any single option is rarely if ever the thing that pushes a product past the line into over-complexity.

But a line is important and in this case adding an option for both behaviors goes, in my view, past it.

Thus, while I acknowledge and respect the place the request comes from, I think it's helpful for me at this point to indicate that I don't see this particular design choice changing. Achieving the second option of a totally "invisible" cue can be accomplished in the ways others have described and I think those are much preferable to adding a new mode in which the playhead behaves substantially differently and the cues have two extremely similar but subtly different "disable" options.

Best,

Chris

[Rob Ram]

so we are back to the "I dont use it that way so it shouldn't be added as an option.. " replies.

personally i use it the way it works now.. 

but having a 2 step process of adding GOTO cues and then making a separate list that turns those on and off thru a disarm cue is very insane  compared to a simple tick box for each behaviour DISARM as it is now and below it SKIP.

being invisible seems sorta weird .. as someone who disagreed with Vinny pointed out.. how would it be edited. 

but the play head skipping over cues is not  possible?? .. so that the little Disarm tick box had a Skip tick box below it. it's not confusing..  you don't have to use it... if you still want to use some crazy GOTO/ separate cuelist process. 

but if it is just a matter of figure53 not knowing how to and/or not being able to devote coding time to it.. thats another story. 

the function would definitely be useful. the only reason someone came up with the GOTO /separate cuelist DISARM the GOTOs is because there is no way of  clicking a SKIP tick box currently. To dismiss it as not needed or too confusing to step over a line in the sands of coding.. seems silly. 

the program is awesome.. so awesome. but sometimes it seems people dismiss a request from clients that have spent a pretty large amount of money on your software. 

i hope this isn't a trend. that's how companies end up going under.. and i love my qlab too much.

cheers

robert

[Dave "luckydave" Memory]

On Monday, May 12, 2014 at 7:23 PM, Rob Ram wrote:

but if it is just a matter of figure53 not knowing how to and/or not being able to devote coding time to it.. thats another story. 

...and...

 

To dismiss it as not needed or too confusing to step over a line in the sands of coding.. seems silly. 

the program is awesome.. so awesome. but sometimes it seems people dismiss a request from clients that have spent a pretty large amount of money on your software. 

Respectfully, Rob: this offends me personally and professionally. What gives you the idea that the people who code QLab are lazy? Is it the 18 updates QLab has received since its release only 12 months ago?

-- 

luck...@figure53.com 

[Christopher Ashworth]

Rob,

I don't know how to reply constructively. I feel pretty frustrated.

We want to respect and honor feedback, and do the best we can to make a product that fits within the space formed by that feedback. It's an imperfect process and the total feedback will not carve out a single, simple space which represents the ideal product for everyone. It creates a set of conflicting, overlapping spaces that we must make choices to resolve.

Not everyone will agree we have made the right decision for every single choice, but we can at least promise to try hard to honor all that input while making those choices.

I'd ask that, for this to be a productive exchange, a level of respect is necessary on both ends. We offer in good faith our best efforts to serve everyone here, to the best of our ability. I am consistently reminded how much I have to learn from everyone here. If sometimes we think it is better to say "no" to a feature it is not out of disrespect, but out of the genuine, careful, considered effort to make QLab as good as we can make it.

Thanks,

Chris

[fishmonkey]

hi Chris,

i get where you are coming from with the concerns about feature creep, however the extra option would avoid the need to create unwieldy workarounds that are far more confusing to setup and maintain. having multiple options for cues quickly available when teching or even touring is a pretty basic need. when you are working fast on the fly, the less fiddly workarounds required the better, IMO.

[Christopher Ashworth]

I agree that a goto cue is fiddly and wouldn't want to use that myself.

the group cue set to "start all simultaneously", and which contains several options, leaving only one enabled at a time-- that seems to me not so fiddly, and is rather more clear in some ways. "Here is a section that has multiple options, it can be closed to hide the extra stuff or opened to review the options"

That's not terrible, no?

(mobile)

[fishmonkey]

yep, you are right, that's not terrible at all. i was getting overly fixated on the extra-cue-lists-with-gotos solution that is mentioned above...

[fishmonkey]

that said, i personally would still much prefer a way to have a cue not run at all, so it is essentially invisible to the flow of the show...

[Robert Ramirez]

First of all you've taken some liberties with what I meant.

I don't think there is anything lazy about not being able to find time for this feature.. You guys at Figure53 know what you can or can't tackle. I realize there is a limited amount of time to be devoted to added features. Especially because of updates for bugs or other features.

So I'm very confused as to how you inferred lazy.

That was the furthest thing on my mind.

And since I don't understand coding. And can admit it with out making excuses.. I don't know if skipping cues is just not possible for some reason that we aren't thinking about while requesting the feature.

But that doesn't mean that saying there is this other way of doing it so we're not going to do it. Is the right way to handle it per se.

I think someone is jumping to conclusions this time

Sorry you misunderstood
Cheers
Robert

--

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

---

You received this message because you are subscribed to a topic in the Google Groups "QLab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qlab/6PeZjJRo1KI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qlab+uns...@googlegroups.com.

[Robert Ramirez]

I don't believe there was anything disrespectful in what I wrote.

I already explained to Dave that he clearly misunderstood.

If stating my opinion in itself is disrespectful, then I don't know what a group like this is for..

I get the impression that if anything contradictory is said you guys take it super personally.

This is the second time I've commented on a thread where I disagree with someone from figure53. When I don't disagree everyone seems chill.

When I do disagree people get super sad or annoyed or what have you.

You guys are a million+ dollar company.. Or there abouts.. You will run into people disappointed or disagreeing with you..

I suggest you don't take it every time as disrespectful.

Cheers
Respectfully
Robert

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab

Follow Figure 53 on Twitter: http://twitter.com/Figure53

---

You received this message because you are subscribed to a topic in the Google Groups "QLab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qlab/6PeZjJRo1KI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qlab+uns...@googlegroups.com.

[Sean Dougall]

It may be helpful to go into a little more detail of what Chris was saying.

If a Skip checkbox existed in addition to the current Disarm checkbox, we’d need to determine how exactly it would behave in different scenarios, and make sure it was consistent. If you just had a list of individual cues that were all fired by hitting the spacebar and going down the list, then it seems obvious; a cue with Skip checked would have no action, and the playhead would skip over it and go to the next cue.

But what if the cue being skipped had an auto-continue to another cue? Would the playhead skip just the one cue and land on a cue it normally never touches—which seems really confusing to me—or would it skip the entire sequence instead? What if the Skip option is set on a cue in the *middle* of the sequence? The original proposal was that the sequence would then go on and only that cue would be skipped, but that’s an entirely separate question from what happens to the playhead, and seems like it would have the opposite answer. Then what if you check Skip on a group containing other cues? Would a skipped start-and-enter group behave the same as a skipped start-and-go-to-next group? Can its behavior be reduced down to a consistent set of rules, or would certain scenarios need to be hard-coded in? And if its behavior changes from one scenario to another, how do we convey that to the user?

Also, one of the major benefits of disarming is that you can use arm and disarm cues to change whether a cue is armed conditionally as part of the cue list. Would we need to add two new cue types to set and unset the Skip flag?

These are all questions we’d need to consider (and I’m sure there are many others, as that’s just off the top of my head), because any new feature that involves a substantial deviation from how QLab normally works will also involve a substantial amount of extra complexity under the hood, which brings in potential errors and unforeseen edge cases. So we’ll never make such a change lightly. If there’s an alternative that isn’t too onerous, we will generally prefer that over a new feature.

One of the guiding principles of QLab is that it’s designed to give you a set of building blocks that you can use in extremely flexible ways to achieve complex goals, but without getting in the way of simpler tasks. Sometimes that means you have to do some building when you might not expect to—there are countless situations where one could envision adding an option as a shortcut, but if we did all of them, QLab would be a sea of buttons and checkboxes, with unpredictable side effects all over. What I believe Chris was getting at is that, while this looks on the surface like just one little checkbox and not that big a deal, it ventures much farther into complexity and nebulous behavior than it seems from the UI.

As for your email: People disagree with us on the list all the time. In fact, the very possibility of using goto cues in this case is because of the lively but (mostly) civil debate that has happened right here; v2’s goto cue had a very different function, and we acknowledged that it was counterintuitive and changed it as soon as we had an opportunity with a major version update. And you should see some of the debates that happen internally in our chat room about things like this. In particular, get Chris and Andy and me all fired up on a topic at once, and whoo boy!

That’s what drives QLab development. We thrive on it. You’re certainly free to disagree with us, and we’ll do our best to acknowledge and address your points appropriately and with an open mind. We ask the same of you in turn; please don’t call us dismissive if we don’t take every suggestion. Even more importantly, please don’t use words like “very insane” or “crazy” to describe other people’s suggested workflows, even if they don’t work for you. Be kind to the professionals who have volunteered time out of their day to try and help you. We would like them to know they’re appreciated so they'll stick around and continue making the QLab community the incredible phenomenon that it is!

Cheers,
Sean

[Robert Ramirez]

Of course the assumption I could make is that you are implying.. I'm not a professional.

But since I'm mature and confident I will merely assume you weren't trying to be disrespectful.

I expressed my opinion of another "professional's work flow" there is little to no need of making this into a bigger deal than it is.

But I do appreciate your response as to why it is considered by Figure53 at large too confusing to implement.
I appreciate you taking the time to explain.. You'd be surprised what a difference it makes.

Cheers.
Robert

On May 12, 2014 11:18 PM, "Sean Dougall" <se...@figure53.com> wrote:

It may be helpful to go into a little more detail of what Chris was saying.

If a Skip checkbox existed in addition to the current Disarm checkbox, we'd need to determine how exactly it would behave in different scenarios, and make sure it was consistent. If you just had a list of individual cues that were all fired by hitting the spacebar and going down the list, then it seems obvious; a cue with Skip checked would have no action, and the playhead would skip over it and go to the next cue.

But what if the cue being skipped had an auto-continue to another cue? Would the playhead skip just the one cue and land on a cue it normally never touches--which seems really confusing to me--or would it skip the entire sequence instead? What if the Skip option is set on a cue in the *middle* of the sequence? The original proposal was that the sequence would then go on and only that cue would be skipped, but that's an entirely separate question from what happens to the playhead, and seems like it would have the opposite answer. Then what if you check Skip on a group containing other cues? Would a skipped start-and-enter group behave the same as a skipped start-and-go-to-next group? Can its behavior be reduced down to a consistent set of rules, or would certain scenarios need to be hard-coded in? And if its behavior changes from one scenario to another, how do we convey that to the user?

Also, one of the major benefits of disarming is that you can use arm and disarm cues to change whether a cue is armed conditionally as part of the cue list. Would we need to add two new cue types to set and unset the Skip flag?

These are all questions we'd need to consider (and I'm sure there are many others, as that's just off the top of my head), because any new feature that involves a substantial deviation from how QLab normally works will also involve a substantial amount of extra complexity under the hood, which brings in potential errors and unforeseen edge cases. So we'll never make such a change lightly. If there's an alternative that isn't too onerous, we will generally prefer that over a new feature.

One of the guiding principles of QLab is that it's designed to give you a set of building blocks that you can use in extremely flexible ways to achieve complex goals, but without getting in the way of simpler tasks. Sometimes that means you have to do some building when you might not expect to--there are countless situations where one could envision adding an option as a shortcut, but if we did all of them, QLab would be a sea of buttons and checkboxes, with unpredictable side effects all over. What I believe Chris was getting at is that, while this looks on the surface like just one little checkbox and not that big a deal, it ventures much farther into complexity and nebulous behavior than it seems from the UI.

As for your email: People disagree with us on the list all the time. In fact, the very possibility of using goto cues in this case is because of the lively but (mostly) civil debate that has happened right here; v2's goto cue had a very different function, and we acknowledged that it was counterintuitive and changed it as soon as we had an opportunity with a major version update. And you should see some of the debates that happen internally in our chat room about things like this. In particular, get Chris and Andy and me all fired up on a topic at once, and whoo boy!

That's what drives QLab development. We thrive on it. You're certainly free to disagree with us, and we'll do our best to acknowledge and address your points appropriately and with an open mind. We ask the same of you in turn; please don't call us dismissive if we don't take every suggestion. Even more importantly, please don't use words like "very insane" or "crazy" to describe other people's suggested workflows, even if they don't work for you. Be kind to the professionals who have volunteered time out of their day to try and help you. We would like them to know they're appreciated so they'll stick around and continue making the QLab community the incredible phenomenon that it is!

Cheers,
Sean

[fishmonkey]

my initial thoughts would be for QLab to completely ignore a 'skipped' cue, as if the cue was actually deleted from the workspace. that would help avoid all the other permutations that make implementation a minefield...

[Nigel Hogg]

So, as I see it, if someone like me, or Vinny, has a simple show consisting of, say, 10 audio cues and we trigger the next one as required with a 'go'.
Now and then, we wish to miss out a cue. Not often, just now and then. So we want to leave it in the list so it's there when we need it. If we disarm it, we have to remember to step to the next cue, otherwise when we 'go' we fire a disarmed cue and nothing happens. As I see it, our simplest workaround seems to be that, say the cue we need to miss is cue nunber 5. We could make group 4 a fire all group cue containing audio cue 4, and a go to cue targeting cue 6 with a pre- wait of just over the length of audio cue 4, and which is normally disarmed. Then, if we wish to miss out cue 5, we arm the normally disarmed go to cue and our next 'go' command fires cue 6.
I can't help feeling a checkbox would be much simpler..........
By the way, I do normally deal with much more complex workspaces than this, and am not averse to complicated workarounds, but I feel simpler would be better.

Nigel

[Tyler]

I think the 'treat this as deleted' feature is much, much, much needed! Disarm has little use in most situations for me, I end up either deleting said cue or moving it which can get tricky.

[Lucas Krech]

Q1 media plays
Q2 media plays follow to goto 4
Q3 media plays
Q4 media plays

The goto is armed or disarmed as needed to skip 3. Fairly clean and works with QLab as is. Not really different than a checkbox doing what you ask. If you have, say, ten complex versions if this then you can easily make hotkey triggerable groups of arm/disarm cues to load whatever version of the show you need.

-L

*insert witty mobile device advertising here*

[micpool]

In the interests of world peace and harmony here is an example workspace with 2 script cues.

Highlight the block of cues you want to skip. PRESS 1

These cues will now be skipped.

Highlight the goto cue at the top of any block of cues that is skipped PRESS 2

The skipped block will be restored to normal function.

As usual test before deployment in critical situations! I knocked this out in half an hour so there may be things that I haven't thought through.

It will overwrite any auto continue on the cue above the skipped block if present

It will probably not survive a renumber.

It won't cope with a skipped block inside another skipped block

But as everything it does is clearly visible in the cue list it's pretty easy to sort out if it goes wrong.

Mic

[Chris Ashworth]

Mic, this is so lovely. Thank you for doing such a cool thing and sharing it.

-C

Highlight the block of cues you want to skip. PRESS 1

These cues will now be skipped.

Highlight the goto cue at the top of any block of cues that is skipped PRESS 2

The skipped block will be restored to normal function.

[modeland]

Necro-ing this thread. 

I understand that in show situations going through disarmed cues might be important/sensible, but there's definitely situations in rehearsal (for theatre in my case) where being able to skip cues on a temporary basis is very useful, without needing to move them to a separate list or delete them. A very common example would be during cue-to-cue, when the director might say "can we try an option where we don't have this sound". It would make total sense for me to be able to skip that cue that the director doesn't want to hear for now, and be able to run the next one, and without needing to ADD GoTo cues, and I don't want to have to worry about deleting those temporary GoTo cues. AND, if the director changes his/her mind, I can simply un-skip the cue.   

Would it not be a fairly simple solution to add a "skip" checkbox in the Basics window, under the "armed" checkbox? 

[Sam Kusnetz]

On Jul 29, 2022 at 10:51:26 AM, modeland <heidi...@gmail.com> wrote:

Would it not be a fairly simple solution to add a "skip" checkbox in the Basics window, under the "armed" checkbox? 

Hello

If you read the whole thread, you’ll find a thorough discussion of why that is not in fact at all simple. The widely varied conditions in which people use QLab add up to it being very difficult to accurately design what “skip” might mean.

Temporarily removing the cues from the cue list and placing them in another list is simple too, and rather fail-safe.

Best

Sam

—

Sam Kusnetz (he/him) | Figure 53

s...@figure53.com