[QLab] Expected behaviour?

[Rich Walsh]

Are the following expected (and desirable), or should I file them on the Tracker?

1. Drag & drop doesn't activate QLab: you have to click on QLab to work on a cue after you have dragged a file into it.

2. Using a slider in the Active Cues list resets an Audio Cue's levels to those it would have had when first loaded, overriding any fades that have happened (from the manual: "Volume levels are reset on a cue after it has been stopped and reloaded" - but does fast-forwarding an Active Cue count as stopping & reloading?). This somewhat limits the functionality for me...

Rich
________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com

[Rasmus Kreiner]

And just to add to the second part: Any fade also includes the integrated fade envelope.

Sendt fra min iPhone

[Christopher Ashworth]

Finally, after your patient waiting:

On Aug 29, 2010, at 12:08 AM, Rich Walsh wrote:

> Are the following expected (and desirable), or should I file them on the Tracker?
>
> 1. Drag & drop doesn't activate QLab: you have to click on QLab to work on a cue after you have dragged a file into it.

This is expected, as it's a standard behavior in Mac apps. I suppose it could be modified, but it isn't the way the OS X handles focus changes by default.

> 2. Using a slider in the Active Cues list resets an Audio Cue's levels to those it would have had when first loaded, overriding any fades that have happened (from the manual: "Volume levels are reset on a cue after it has been stopped and reloaded" - but does fast-forwarding an Active Cue count as stopping & reloading?). This somewhat limits the functionality for me...

At a pure "reporting what the code is actually doing" level, the scrubbing in the active cues panel invokes:

[...stuff...]

[_cue pause];
[_cue onDeckAt:loadTime];
if (wasRunning)
[_cue start];

[...stuff...]

And the onDeckAt: call does, as you say, reset the volume levels of the cue to their initial levels.

I agree that this is not a desirable outcome when scrubbing in the active cues panel.

There may or may not be a quick fix for this. I've created a ticket for it here:

http://tracker.figure53.com/qlab/ticket/623

Best,
Chris

[Rich Walsh]

On 13 Sep 2010, at 18:02, Christopher Ashworth wrote:

>> 1. Drag & drop doesn't activate QLab: you have to click on QLab to work on a cue after you have dragged a file into it.
>
> This is expected, as it's a standard behavior in Mac apps. I suppose it could be modified, but it isn't the way the OS X handles focus changes by default.

So it is! Never noticed that before; maybe I've always been dragging _into_ the active application. As QLab occupies the whole screen, I tend to drag from the active application into QLab - and, bizarrely, the other app that promotes this way of working is Pro Tools, which behaves in the non-standard way and activates! Hence the confusion.

>> 2. Using a slider in the Active Cues list resets an Audio Cue's levels to those it would have had when first loaded, overriding any fades that have happened (from the manual: "Volume levels are reset on a cue after it has been stopped and reloaded" - but does fast-forwarding an Active Cue count as stopping & reloading?). This somewhat limits the functionality for me...
>

> There may or may not be a quick fix for this. I've created a ticket for it here:
>
> http://tracker.figure53.com/qlab/ticket/623

That seems to cover it...

Thanks.

Rich