QLab: Is this a bug?

I got bit tonight by QLab 4.9.whatever, twice. I can't imagine I never did either of these things before, but they never bit me before...

1) Cut a cue, the cue before which has an auto-follow/continue. That cue still has the auto, and automatically fires... some other probably unrelated cue you weren't interesting in overlapping with the right one. (I think I had one of each of those, or maybe one was...):

2) Copy a cue which has an auto-continue/follow on it, paste it into some other place... where it then still has the auto, and proceeds into some other probably unrelated cue you weren't interesting in overlapping with the right one.

I would assert, both as a production guy and a software designer for a minute or two, that if you cut a cue, the one before it should lose its outgoing auto, and that if you paste in a copy of a cue or series, that the last one pasted in should lose it's auto, since in both cases, the context which makes that auto-follow/continue the right thing to do has been lost.

A) Am I right in believing that this behavior is as-designed in 4.9?

B) Was it a change from earlier versions? Why

C) If A) Am I wrong in my assertions that the context-loss should motivate the dropping of the relevant links?

D) If A) Is Chris gonna tell me Broadway wants it this way?

I don't think either of those behaviors are new, and I do think they work exactly as they should. Obviously there's some opinion involved, but in both cases the actions you're describing are open-ended: it's "play next" not "play this specific cue", so it's right that it should stay as-is unless you explicitly change it to something else. Software that tries to anticipate what you want it to do is helpful when it's right, but exceptionally frustrating when it guesses wrong. If I'm copying something, I expect an exact copy on the other end (unless it's a parametric copy/paste where I'm only taking certain attributes). Same for cutting or deleting: only the cue I acted on should be affected. The only exceptions to that are other things that uniquely target that cue (since those links would no longer have a valid target).

That's the behavior I would expect and is the same as in my software.

When you delete a cue, you are telling the program you don't want or need that look anymore and it can't assume that now don't want the look from before to transition to the next automatically.

When you copy a cue, you copy all its attributes (for better or for worse) and expect them to be there when you paste.

At least that's what I would expect. Where it gets tricky is copying a block of cues with both what I would call a 'starter' cue and it's corresponding fade or control cue. In this case, you do want the fade cue to point to the new pasted position of the 'starter' cue.

Indeed, the automatic transition to the next cue seems to just be an attribute of the first cue, and so gets copied/pasted/deleted along with it. It's somewhat like a word processor, where if you copy a few words from a section that's (say) a blockquote that is italicized, and paste them into the body of your text in normal type, they often will keep their italics because the program treats that as an attribute of the individual characters rather than a property of the context they're in--even though the latter is what you're thinking of in an editorial sense.

It sounds like in your mind it ought to be more of a separate thing, a sort of transition or linkage between two cues, rather than a part of the cue. That's a perfectly reasonable way of looking at things, but not (apparently) how the software handles it internally. You're stuck with the program's view of how it's world is not being quite what you think it is, or at least what it should be.

As a computer programmer by training, I definitely have a bit of understanding that it's much harder to think like a user than one would initially assume, and what seems obvious and correct to a developer who sees the insides of the program and has an intimate understanding of how its parts all fit together might not be at all what a user is expecting from the outside. Occasionally, too, when trying to do what is intuitively correct, one may run into a whole long list of odd edge cases that are very tricky to handle and make doing the "right" thing nearly impossible. Good user interface design and user experience design is one of the hardest parts of application programming, and needs somewhat different skills and mindset than coding an algorithm to actually do whatever work the program is designed to do.

(Apologies if I've rambled a bit excessively here.)

Ok, so we are confirming A) it's purposeful and B) it's not new.

We seem to disagree, though, on C) should it work like that.

My assertion is this: if you *leave the links* in the places I've mentioned, and that's the wrong thing to do, *the audience is gonna notice*. You will either fire the next cue at the end of the current one unexpectedly when your attention is elsewhere. Or you will fire it at the *beginning* of the cue and they'll overlap, which is worse.

If you *take off those links*, and leaving them was the *right* thing to do, then all that happens is nothing, and you the board op have to tap the Go button an extra time before you fix it.

I know which of those ways *I* want my power tool to fail, as a operating professional. The job of the computer is to make my life *easier*, not harder. If it imposes a bunch of unnecessary stress on me, this is bad.

This is called the Principle of Least Astonishment:

https://en.wikipedia.org/wiki/Principle_of_least_astonishment

I too am a software designer by trade, and I've been doing it for a minute, and I try really hard to violate POLA only when there is a clear and compelling reason to do so... and switching hats to A1, I don't think the reasons here for keeping links whose context has been ripped away from them is either clear, or compelling; rather the reverse.

And I will point out here also that a large part of the reason why it's important to do this *is because of the hoops QLab makes you jump though to construct logic to get your work done* *because of the assumptions baked into its design*.

If I *could* do the links backwards from the follow-up cues, we wouldn't be having this conversation. But I don't feel like getting in a fight with Chris about backwards combatability. Chris is, by definition, always right about QLab, even when he's wrong.

DrewE said:

Indeed, the automatic transition to the next cue seems to just be an attribute of the first cue, and so gets copied/pasted/deleted along with it. It's somewhat like a word processor, where if you copy a few words from a section that's (say) a blockquote that is italicized, and paste them into the body of your text in normal type, they often will keep their italics because the program treats that as an attribute of the individual characters rather than a property of the context they're in--even though the latter is what you're thinking of in an editorial sense.

It sounds like in your mind it ought to be more of a separate thing, a sort of transition or linkage between two cues, rather than a part of the cue. That's a perfectly reasonable way of looking at things, but not (apparently) how the software handles it internally. You're stuck with the program's view of how it's world is not being quite what you think it is, or at least what it should be.

Click to expand...

Not quite. I'm not talking about how links *run*. I'm talking about *how you edit the cues that have them attached, and whether the editor should be smarter than it apparently is about the context of that.

dbaxter said:

That's the behavior I would expect and is the same as in my software.

When you delete a cue, you are telling the program you don't want or need that look anymore and it can't assume that now don't want the look from before to transition to the next automatically.

Click to expand...

See, this is where we differ.

My assertion is: it cannot *assume you DO want that link*, which you set when it pointed to a cue you knew about, and now Jumps, in the immortal words of IBM mainframe programmers, To Fishkill. At the *very* least, it should ask.

Malabaristo said:

If I'm copying something, I expect an exact copy on the other end (unless it's a parametric copy/paste where I'm only taking certain attributes). Same for cutting or deleting: only the cue I acted on should be affected. The only exceptions to that are other things that uniquely target that cue (since those links would no longer have a valid target).

Click to expand...

I feel like I should note, here, that if you copy a block where one cue is, say, a stop or fade that acts on another cue in the block, *QLab gets that right*, making the new fade affect the *new* cue... *even though that new cue doesn't have a cue number to hook it onto*. And if you then number the source cue, of course, the fade cue is properly relabeled.

In short. QLab *already* performs some 'magic' in these contexts, and knows which cues have others as context and which don't.

Jay Ashworth said:

A) Am I right in believing that this behavior is as-designed in 4.9?

Click to expand...

Yep, as designed

Jay Ashworth said:

B) Was it a change from earlier versions? Why

Click to expand...

Nope, not a change, that's been how it's worked as long as I've used QLab (15 years now?)

Jay Ashworth said:

C) If A) Am I wrong in my assertions that the context-loss should motivate the dropping of the relevant links?

Click to expand...

You only lost context in your mind and your own personal workflow. The auto-follow is only in context to the cue the auto-follow is selected on, it is not a property of anything outside of its own bubble either before or after. You keep talking about the auto-follow as if it's a link, it's not a link to anything - It's a command of the currently playing cue and is context-less and link-less outside of the cue it's selected on. A fade cue is a link to a media cue, but an auto-follow/continue is a command in the same way a Pre or Post wait is a command of the current cue.

Jay Ashworth said:

D) If A) Is Chris gonna tell me Broadway wants it this way?

Click to expand...

I can't speak for any of Broadway but myself, but the program is working as intended. I don't want the program to make any decision for me. The auto-follow is a feature of last resort for me, I almost never touch it but when I do it's because I really need it. If I'm batch editing a bunch of pre-show music and the Director comes to me and says I need to cut half the songs I don't want the auto-follows on prior cues to just evaporate because I went in and axed a bunch of cues in the Group. Likewise, if I'm re-ordering my pre-show music and copying and pasting things I want the auto-follows to remain with the cues because otherwise it's just one more button press. I like knowing each cue lives in its own bubble until acted on by another command.

dbaxter said:

When you copy a cue, you copy all its attributes (for better or for worse) and expect them to be there when you paste.

Click to expand...

Shift+Apple+V is the selective paste! Best thing I wish I knew when I started working in QLab.

themuzicman said:

You only lost context in your mind and your own personal workflow. The auto-follow is only in context to the cue the auto-follow is selected on, it is not a property of anything outside of its own bubble either before or after.

Click to expand...

Sure it is. My own personal workflow, not to put too fine a point on it, is the only thing that matters to me. And clearly, since that command *makes that cue interact with other cues as it is run*, there is outside context related to it; with all due respect, Muze, its ridiculous to suggest otherwise. When I run that cue with the link *it is going to do something else besides play that cue*, and *what it will do* depends on context. If the program sees that I am changing what that context is, I don't think it's at all unreasonable for the program to *do something* about that -- it's a damn power tool; it's job is to *take workload off of me* in a fast-paced, high-pressure environment.

You keep talking about the auto-follow as if it's a link, it's not a link to anything - It's a command of the currently playing cue and is context-less and link-less outside of the cue it's selected on. A fade cue is a link to a media cue, but an auto-follow/continue is a command in the same way a Pre or Post wait is a command of the current cue.

Click to expand...

Yes, you've nailed it: it is contextless, *and that is bad*; it *should* be smarter than that -- this is my entire proposition.

[ As for Broadway, I've brought up, over the last 5 years or so I've been working with Q, a couple other things in this general vein, on the F53 forums, and Chris Ashworth, whom I gather is the lead designer/programmer for Q, and also no relation has responded with replies that amounted to "Broadway doesn't want it that way".

Now, there are 53 or so Broadway theatres, and maybe 40,000 other people using Qlab, so that doesn't sound like a great answer to me, but I'm not the lead programmer... ]

Hey! Welcome back, Ron!