[QLab] Triggers and cue list scroll
Mic Pool
If I hit the keyboard trigger the program change fires, and nothing else happens, which is good, but if the same cue is triggered by the MIDI trigger the cuelist scrolls to the bottom which is not in the least bit helpfull and quite unsettling for the operator.
Is there a reason why different methods of triggering a cue should result in different behaviors?
Best regards
_________________
Mic Pool
m...@micpool.com
www.micpool.tv
_________________
________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com
Follow Figure 53 on Twitter here: http://twitter.com/Figure53
Christopher Ashworth
The reason for the difference is because MIDI triggers ended up being frequently used as a way to fire an entire show, and people wanted the cue list to track along for the operator. It was reported frequently that having the cue list not scroll as it was triggered by MIDI was not the least bit helpful and quite unsettling for the operator. :-)
Hot key triggers, in contrast, tend to be more of a random-access trigger mechanism.
Certainly in this case the scrolling behavior is not helpful.
-C
On Aug 24, 2011, at 2:24 AM, Mic Pool wrote:
> So, I Am designing a Dsm operated show with some radio mics and have put a cue at the end of the cue list list with keyboard and Midi triggers to take the mics out in case of a problem by sending a program change to the mixer.
>
> If I hit the keyboard trigger the program change fires, and nothing else happens, which is good, but if the same cue is triggered by the MIDI trigger the cuelist scrolls to the bottom which is not in the least bit helpfull and quite unsettling for the operator.
>
> Is there a reason why different methods of triggering a cue should result in different behaviors?
>
________________________________________________________
Jeremy Lee
On Aug 24, 2011, at 4:18 AM, Christopher Ashworth wrote:
> Hi Mic,
>
> The reason for the difference is because MIDI triggers ended up being frequently used as a way to fire an entire show, and people wanted the cue list to track along for the operator. It was reported frequently that having the cue list not scroll as it was triggered by MIDI was not the least bit helpful and quite unsettling for the operator. :-)
>
> Hot key triggers, in contrast, tend to be more of a random-access trigger mechanism.
>
> Certainly in this case the scrolling behavior is not helpful.
>
> -C
>
> On Aug 24, 2011, at 2:24 AM, Mic Pool wrote:
>
>> So, I Am designing a Dsm operated show with some radio mics and have put a cue at the end of the cue list list with keyboard and Midi triggers to take the mics out in case of a problem by sending a program change to the mixer.
>>
>> If I hit the keyboard trigger the program change fires, and nothing else happens, which is good, but if the same cue is triggered by the MIDI trigger the cuelist scrolls to the bottom which is not in the least bit helpfull and quite unsettling for the operator.
>>
>> Is there a reason why different methods of triggering a cue should result in different behaviors?
--
Jeremy Lee
Sound Designer, NYC - USA 829
http://www.jjlee.com
sam kusnetz
if you put these cues in a separate cue list you should have no problems I think.
sam
sam kusnetz
I don't remember it that way... as I recall, the consensus was that drag-and-drop was fairly imperfect but that it worked well enough, didn't require any special education to understand, and there were bigger fish to fry.
someone (andy?) suggested that either drag-to-assign or drag-to-move require a modifier key, and I'm inclined to agree. I try not to use drag-to-assign ever; instead I number my cues and target fades via the keyboard.
or via my iPad qlab remote :) but more on that later...
> But quite often hire rigs come with non standard compact keyboards and trackpads which aren't easily configured through the system preferences
tap-to-click is the work of the devil, and if a rental house gives you a trackpad for which it can't be turned off, I would consider that a complete deal-breaker.
cheerio
El Armstrong
Sent by smoke signal
or via my iPad qlab remote :) but more on that later...
Mr. Matthew Troy Parker
I think you added that to fix the issue we had triggering videos from the light board with MSC. The issue we have slaving Qlab to the light board with MSC is that the playback position cursor doesn't advance with "GO CUE#". The next Cue doesn't get preloaded, so load cues have to be added to every Cue, and if the board-op needs to manually trigger a cue because a light cue that would have trigger Qlab was skipped, they have to move the playback position and hit go rather than just hitting Go if the playback position had been follows the MSC Go's.
Right now cues triggered with MSC Go's act like they are trigger with the preview command instead of a Go command so the playback position doesn't advance and even if we put a "Goto" cue in a cue triggered to move the playback position and load the next Cue, the Goto doesn't operate.
If a cue has a midi or hotkey trigger, I don't think it needs to scroll the window to the cue. Right now we get some weird scrolling the hides the playback position if there is an open group cue with many parts.
With MSC Go commands the behavior most of us expect is for the playback position to "chase" MSC GO cues:
Example 1:
• (MSC go cue matches playback position so playback position advances)
playback position is on cue 1
MSC Go cue 1 sent
Cue 1 executes (like it was trigger with a local go)
playback position advances to cue 2 and loads it
Example 2:
•(MSC go cue doesn't matches playback position so playback position doesn't change)
MSC Go cue 1 sent
Cue 1 executes
playback position stays on cue 3 and loads cue 2
•(MSC go cue doesn't matches playback position so playback position doesn't change but now in sync for next cue)
playback position is still on cue 3
MSC Go cue 2 sent
Cue 2 executes
playback position stays on cue 3 and loads cue 3 (if not already loaded)
• (MSC go cue matches playback position so playback position advances)
playback position is on cue 3
MSC Go cue 3 sent
Cue 3 executes (like it was trigger with a local go)
playback position advances to cue 4 and loads it
Anyone else with another idea please chime in. Even if the Goto cue worked when triggered from MSC go, Start cue, or any other trigger that would be a big help not just as a workaround for this but other complex programing scenarios.
Matthew Parker mailto:Matt_...@Asolo.org
Sound Designer
Asolo Repertory Theatre http://www.asolo.org/
> here: http://twitter.com/Figure53
Rich Walsh
> I think you added that to fix the issue we had triggering videos from the light board with MSC. The issue we have slaving Qlab to the light board with MSC is that the playback position cursor doesn't advance with "GO CUE#". The next Cue doesn't get preloaded, so load cues have to be added to every Cue, and if the board-op needs to manually trigger a cue because a light cue that would have trigger Qlab was skipped, they have to move the playback position and hit go rather than just hitting Go if the playback position had been follows the MSC Go's.
>
> Right now cues triggered with MSC Go's act like they are trigger with the preview command instead of a Go command so the playback position doesn't advance and even if we put a "Goto" cue in a cue triggered to move the playback position and load the next Cue, the Goto doesn't operate.
>
> If a cue has a midi or hotkey trigger, I don't think it needs to scroll the window to the cue. Right now we get some weird scrolling the hides the playback position if there is an open group cue with many parts.
If you are GOing a specific cue then you aren't GOing the cuelist - so it makes perfect sense that the cuelist playhead stays put. If you want to advance through a cuelist linearly then GO the cuelist. If you are GOing specific cues then you are executing random access, so it should fall to you to worry about what needs loading when: if you are expecting QLab to second guess which cue you are intending to GO next and load it for you then you aren't executing random access, and should be GOing a linear cuelist.
I like the fact that using a program change to trigger a specific cuelist makes the playhead behave exactly the same as if you were using the generic "GO current cuelist" from the preferences. I think the scrolling change fixed this for us.
Keep your hotkeys, random access cues and remote-triggred cues in separate cuelists and build loading into them as needed. Keep your linear cuelist that tells the operator where they are in the proceedings as the Main Cue List and GO that list. If you can...
Incidentally, I think the scrolling is separate from the playhead, but I don't have time to check that at the moment.
Rich
Rich Walsh
>> The consensus was that the existing method was right
>
> I don't remember it that way... as I recall, the consensus was that drag-and-drop was fairly imperfect but that it worked well enough, didn't require any special education to understand, and there were bigger fish to fry.
>
> someone (andy?) suggested that either drag-to-assign or drag-to-move require a modifier key, and I'm inclined to agree. I try not to use drag-to-assign ever; instead I number my cues and target fades via the keyboard.
How about alt-drag to copy (fairly standard across the Mac OS)? On the whole, unmodified dragging seems to imply moving (eg: Finder, TextEdit, etc). Excel uses shift-drag to move a line, which feels pretty natural - but maybe moving should be unmodified and assigning should require the modifier key? Which do you do more often - and which is more catastrophic? Perhaps the easiest answer is a preference - with some kind of notification in the workspace (like a tooltip, or a tool in the toolbar that changes icon with modifier keys, or something)?
>> But quite often hire rigs come with non standard compact keyboards and trackpads which aren't easily configured through the system preferences
>
> tap-to-click is the work of the devil, and if a rental house gives you a trackpad for which it can't be turned off, I would consider that a complete deal-breaker.
I've not managed to find a hardwired trackpad that doesn't do this (other than a graphics tablet, which is overkill). If you want a 19" keyboard with integral trackpad and USB cable you're stuck with tap-to-click I think...
Rich
Mic Pool
Opt drag to copy
Cmd drag to assign
Shift drag to move
With an option in preferences to switch the modifiers on so that the current method is retained for those that value having a hand free for other things when programming, over complete confidence they haven't re-ordered or reassigned cue list elements
A keyboard with integrated trackpad is the most sensible option for uk shows operated by stage management from the prompt corner as there is never room for anything more and the most dangerous option of all is a mouse balanced on top of a cuelight desk or next to the prompt copy. The tap to click thing is a real pain though.
Mic
Mic Pool
When I've done this in the past, I've put those "fire at will" cues in a separate cue list so it didn't affect the operator. Would that work for you in this case?
Christopher Ashworth
> Perhaps the current method should be retained with a checkbox next to the Midi trigger field to allow the trigger to not scroll the cuelist
I can't say I'm a fan of that approach — I'm looking for ways to remove checkboxes rather than add them. I like the separate cue list method.
-C
Christopher Ashworth
> Perhaps the easiest answer is a preference
The trouble with preferences is that they add state your mind has to track (which way is the toggle flipped?) and make the program less predictable (when I sit down to a QLab workstation, how will it behave when I do a basic editing operation?)
Preferences are, to me, a last resort.
Using a modifier to move is something I'm skeptical of, since as you say it's the opposite of how list views work in OS X by default.
Hmmm. I guess I'm not 100% sure I understand the specific operations that are getting borked. What is:
A) the action that you're trying to do, and
B) the thing that happens instead?
-C
Rich Walsh
> Hmmm. I guess I'm not 100% sure I understand the specific operations that are getting borked. What is:
>
> A) the action that you're trying to do, and
> B) the thing that happens instead?
Copying's simple: there isn't currently an option to alt-drag; it would be nice if there were.
The recurring issue I think we all encounter is when you're trying to drag a cue to insert it between two others and end up assigning it to one of them instead. When working at high speed you may not notice that you have done this until it is too late to go back and undo it (without losing lots of other work).
I don't think there is a direct analogy in the Finder as there is only the concept of "moving" not "assigning" - so perhaps "assigning" is sufficiently non-OS-like to merit a modifier; this would prevent a lot of accidents I think.
Rich
Christopher Ashworth
> On 24 Aug 2011, at 22:22, Christopher Ashworth wrote:
>
>> Hmmm. I guess I'm not 100% sure I understand the specific operations that are getting borked. What is:
>>
>> A) the action that you're trying to do, and
>> B) the thing that happens instead?
>
> Copying's simple: there isn't currently an option to alt-drag; it would be nice if there were.
>
> The recurring issue I think we all encounter is when you're trying to drag a cue to insert it between two others and end up assigning it to one of them instead. When working at high speed you may not notice that you have done this until it is too late to go back and undo it (without losing lots of other work).
Gotcha. Thanks. Will explore & experiment.
-C
Mic Pool
Rich, you cite as an example the other case i.e assigning when you meant to move but then seem to suggest that the modifier should be only for the assign operation. I think both moving and assigning drag and drops can have accidental consequences and both need the option of modifiers.
Best regards
_________________
Mic Pool
m...@micpool.com
www.micpool.tv
_________________
Rich Walsh
> Rich, you cite as an example the other case i.e assigning when you meant to move but then seem to suggest that the modifier should be only for the assign operation. I think both moving and assigning drag and drops can have accidental consequences and both need the option of modifiers.
The logic for that was in response to Chris: "Using a modifier to move is something I'm skeptical of, since as you say it's the opposite of how list views work in OS X by default." I was trying to propose a solution that was as consistent with the rest of the Mac OS as possible.
Rich
Mic Pool
On 25 Aug 2011, at 00:07, Mic Pool wrote:Rich, you cite as an example the other case i.e assigning when you meant to move but then seem to suggest that the modifier should be only for the assign operation. I think both moving and assigning drag and drops can have accidental consequences and both need the option of modifiers.
The logic for that was in response to Chris: "Using a modifier to move is something I'm skeptical of, since as you say it's the opposite of how list views work in OS X by default." I was trying to propose a solution that was as consistent with the rest of the Mac OS as possible.
Rich Walsh
Christopher Ashworth
> On 25 Aug 2011, at 00:11, Rich Walsh <rich...@mac.com> wrote:
>>
>> The logic for that was in response to Chris: "Using a modifier to move is something I'm skeptical of, since as you say it's the opposite of how list views work in OS X by default." I was trying to propose a solution that was as consistent with the rest of the Mac OS as possible.
>
> Yes, but surely avoiding mistakes when hastily editing lots of cues in a complex show 10 minutes before the house opens is more important than consistency with the finder.
I used the word "list view", but I shouldn't have. I'm not really thinking of the Finder specifically, I'm thinking of the basic expectation of "moving" as a concept in all OS X applications, which is always simply "drag this thing where I want it to go".
So, what I'm trying to get at is finding a way to eliminate the errors (which are definitely bad news and worth attempting to eliminate) without changing the basic paradigm.
Part of it could be as simple as adjusting the variables that affect how the dragging works in QLab.
Or it could require something more significant. For example, one thought I was finding myself playing with over dinner was "what if it's no longer possible to assign a target by dragging it on to another cue". What if dragging cues within the list is only ever a re-order operation, and never a target operation.
Do people frequently use drag to target cues? I suppose the problem with that is you can't target cues that don't themselves have numbers. Hm.
-C
Mic Pool
On 25 Aug 2011, at 01:34, Christopher Ashworth <ch...@figure53.com> wrote:
> Do people frequently use drag to target cues? I suppose the problem with that is you can't target cues that don't themselves have numbers. Hm.
Thats exactly the problem. Imagine a fire all children with five wavs. The group cue would have a number but the cues within the group probably would not.
The next five cues fade the cues fired in the group one by one. Can only be done by drag and drop.
Having thought about it perhaps a modifier only when assigning would work. It doesn't/solve flicking cues out of order by accident but this is les of a problem.
Mic
Christopher Ashworth
>
> On 25 Aug 2011, at 01:34, Christopher Ashworth <ch...@figure53.com> wrote:
>
>> Do people frequently use drag to target cues? I suppose the problem with that is you can't target cues that don't themselves have numbers. Hm.
>
> Thats exactly the problem. Imagine a fire all children with five wavs. The group cue would have a number but the cues within the group probably would not.
>
> The next five cues fade the cues fired in the group one by one. Can only be done by drag and drop.
>
> Having thought about it perhaps a modifier only when assigning would work. It doesn't/solve flicking cues out of order by accident but this is les of a problem.
Oh, you know, I wonder if one hidden benefit of using a modifier for assignment would be that we could switch to an "assignment-only" mode — and in this mode could adjust behavior & appearance to specifically work best for assignment.
So, for example, I'm imagining that if I hold down a modifier, the ONLY operation I can do is drag on another cue to assign, and perhaps every cue that isn't a valid recipient fades dark, highlighting the cues that will accept your drag.... something like that...
Seems worth an experiment.
-C
Mic Pool
On 25 Aug 2011, at 01:30, Rich Walsh wrote:
>
> Anyway, if the issue is that performing action A can result in action B by accident, only one of them needs a modifier to prevent this occuring:
yes you are right. A modifier for assigning and nothing for moving would work well. Sorry i didn't understand that straight away from your previous post
Mic
Mic Pool
>
> So, for example, I'm imagining that if I hold down a modifier, the ONLY operation I can do is drag on another cue to assign, and perhaps every cue that isn't a valid recipient fades dark, highlighting the cues that will accept your drag.... something like that...
Brilliant
mic
Andy Leviss
<ch...@figure53.com> wrote:
> Do people frequently use drag to target cues? I suppose the problem with that is you can't target cues that don't themselves have numbers. Hm.
The only time I ever haven't was in very, very specific special cases.
99% of the time, dragging is way more efficient. A modifier key
wouldn't hurt that, in my opinion. But it's way quicker than having to
click/hotkey and manually enter the cue number.
Eliminating dragging to target seems very much a
baby-with-the-bathwater solution, at least to me :-)
--A
------------------------------------------------------------------------------------------------
Andy Leviss
ETCP Certified Entertainment Electrician #1251
DucksEchoSound.com
Home of the Perfect Pickle Mini Chain Hoist Controller
and the MR-6 MIDI Remote, 2011 Live Design Product of the Year
Charles Coes
Christopher Ashworth
On Aug 25, 2011, at 9:40 AM, Andy Leviss wrote:
> On Wed, Aug 24, 2011 at 8:34 PM, Christopher Ashworth
> <ch...@figure53.com> wrote:
>> Do people frequently use drag to target cues? I suppose the problem with that is you can't target cues that don't themselves have numbers. Hm.
>
> The only time I ever haven't was in very, very specific special cases.
> 99% of the time, dragging is way more efficient. A modifier key
> wouldn't hurt that, in my opinion. But it's way quicker than having to
> click/hotkey and manually enter the cue number.
>
> Eliminating dragging to target seems very much a
> baby-with-the-bathwater solution, at least to me :-)
Agreed. Officially chucking the idea. :-)
-Chris "Should I be Brainstorming In Public? Dunno, but Gonna do it Anyway!" Ashworth
Mr. Matthew Troy Parker
Unfortunately light boards are generally very dumb with show control our only sends MSC go cue#.
Matt
> ttp://twitter.com/Figure53
Jeremy Lee
On Aug 24, 2011, at 5:22 PM, Christopher Ashworth wrote:
> Hmmm. I guess I'm not 100% sure I understand the specific operations that are getting borked. What is:
>
> A) the action that you're trying to do, and
> B) the thing that happens instead?
--
Jeremy Lee
Sound Designer, NYC - USA 829
http://www.jjlee.com
M. Florian Staab
I've had this same issue with a light board triggering our QLab computer via MIDI Show Control. The way it is set up, lighting triggers some cues, and some cues need to be triggered by our board op, so I need the playback head to scroll as cues are triggered. Since the light board can only trigger specific cues via MSC and not the cue list, the playback head won't move.
I've made the following workaround, which seems a bit clunky, but does what I need it to do.
After each cue triggered via MSC
- Add a load cue to load the next cue in the sequence
- Add a script cue that advances the playhead.
The script cue is:
tell front workspace
set playback position of current cue list to cue "xx"
end tell
(where xx is the next cue you want to jump to)
Hope this helps.
Cheers,
-Staab
--
M. Florian Staab
Sound Design
www.florianstaab.com
+1.440.864.7339
--
>
>
> Unfortunately light boards are generally very dumb with show control our only sends MSC go cue#.
>
>
> Matt
________________________________________________________
luckydave Memory
On Sep 14, 2011, at 2:38 PM, M. Florian Staab wrote:
>
> I've had this same issue with a light board triggering our QLab computer via MIDI Show Control. The way it is set up, lighting triggers some cues, and some cues need to be triggered by our board op, so I need the playback head to scroll as cues are triggered. Since the light board can only trigger specific cues via MSC and not the cue list, the playback head won't move.
How about making a cue list of Start cues, all targeted to the main cue list, and numbering them to match MSC cues from the light board? Then, your regular programming flow isn't interrupted, and the playback position moves naturally, automatically loading and scrolling like you're used to it.
luckydave
luck...@figure53.com