[QLab] Start times lost when audio is replaced
Sten
Related to my problem regarding 20ms of silence at the top of each
cue, I've noticed that the start time of a cue will be lost if a new
audio file is dropped on the cue. For a while I was thinking of
having the music department give me files with 1 bar of lead-in and
roll the start time to 20ms before the first used click. But with the
number of changes coming down the pike that would require resetting
the start time every time I dropped in a new cue, which isn't as
enticing. I guess my question is what is the expected response of an
audio cue with when a new file is dragged on to it? What parameters
are intended to be reset (end time I hope) or retained?
Thanks,
Sten
________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com
Christopher Ashworth
>
> what is the expected response of an audio cue with when a new file
> is dragged on to it? What parameters are intended to be reset (end
> time I hope) or retained?
The start and end times (and the loop start/end times) will be reset
if the file you drag has a different name from the old file. If the
filename is the same as the old filename, the times will be retained.
-C
Sten
subject. When I'm dealing with strictly sound effects resetting all
the points makes sense, I'm often wholesale replacing the idea. When
I'm dealing with track it doesn't work as well. Let's say for example
that we've set up a lot of loop, start and end points on a track and
the composer rebounces the cue with a new mix but exactly the same
timing. He is a wise composer and saves his files with unique names
so that he can figure out which one does what. In the current
configuration I need to write down the points, drag in the file and
then type in the loop points again. Right?
Thanks,
Sten
Christopher Ashworth
> Okay, I feel like there are probably a lot of opinions on this
> subject.
This is true. The current behavior is based on finding a (hopefully)
happy balance across a lot of feedback over the last few years.
> When I'm dealing with strictly sound effects resetting all the
> points makes sense, I'm often wholesale replacing the idea. When
> I'm dealing with track it doesn't work as well. Let's say for
> example that we've set up a lot of loop, start and end points on a
> track and the composer rebounces the cue with a new mix but exactly
> the same timing. He is a wise composer and saves his files with
> unique names so that he can figure out which one does what. In the
> current configuration I need to write down the points, drag in the
> file and then type in the loop points again. Right?
Yes, if you don't want to change the filename for the QLab workspace.
I'd argue that when the file name changes is the appropriate time for
QLab to consider it a "replacement of an idea", and thus change the
start and end times. Previous attempts to be more clever about this
caused people to get cues where the cue would cut off at weird times
because it was using an old end time that they were not expecting.
I'd suggest some possible workflow tips to make this work easier, but
then again I'm not doing it in the field and my ideas may be naive.
Do others on the list have ways that they manage the kind of
complexity that Sten is describing? My own gut instinct would be to
introduce some steps outside of QLab to manage the assets in a way
that allows the composer to save multiple mixes, but allows the
designer to boil any of those possible mixes down to a common filename
for use in QLab.... maybe just some simple prefixes or suffixes that
can be quickly snipped off before dropping into the QLab workspace?
Best,
Chris
Jeremy Lee
(ie not a stop time after the end of a file) another one.
On Oct 20, 2009, at 5:46 PM, Christopher Ashworth wrote:
> On Oct 20, 2009, at 4:51 PM, Sten wrote:
>>
>> what is the expected response of an audio cue with when a new file
>> is dragged on to it? What parameters are intended to be reset (end
>> time I hope) or retained?
>
> The start and end times (and the loop start/end times) will be reset
> if the file you drag has a different name from the old file. If the
> filename is the same as the old filename, the times will be retained.
--
Jeremy Lee
Sound Designer, NYC - USA 829
http://www.jjlee.com
Christopher Ashworth
> This should be an option, and retaining all parameters that are
> legal (ie not a stop time after the end of a file) another one.
I disagree. Too many options are a bad thing.
-C
Dan Scully
Jeremy Lee
arrangement, when one person creates a file of a certain name, nobody
else should change that name. If you do, you'll have no idea where/
when the file came from, or be able to talk easily about it.
I suggest a preference somewhere. "Keep all programmed times with
replacement files?" with Always/ Never/ Ask Each Time/ Ask only if
duration is different. Then everyone can have their cake and eat it
too.
Jeremy
On Oct 21, 2009, at 11:46 AM, Christopher Ashworth wrote:
> I'd suggest some possible workflow tips to make this work easier,
> but then again I'm not doing it in the field and my ideas may be
> naive. Do others on the list have ways that they manage the kind of
> complexity that Sten is describing? My own gut instinct would be to
> introduce some steps outside of QLab to manage the assets in a way
> that allows the composer to save multiple mixes, but allows the
> designer to boil any of those possible mixes down to a common
> filename for use in QLab.... maybe just some simple prefixes or
> suffixes that can be quickly snipped off before dropping into the
> QLab workspace?
--
Jeremy Lee
Sound Designer, NYC - USA 829
http://www.jjlee.com
Christopher Ashworth
(mobile)
Pim
music department. Just for myself I would really prefer to keep
original filenames to be able to identify what versions I'm currently
using.
I wouldn't neccesarily need all those options in preferences, but
having a little screen to ask me what to do (retain or reset timing)
would be lovely.
Cheers, Pim
ps. this makes me think of another time-settings-related question I
had before, but i'll start a new thread for that... ;-)
On 21 okt, 18:10, Jeremy Lee <jeremyli...@jjlee.com> wrote:
> When working with a music department, or any other complex workflow
> arrangement, when one person creates a file of a certain name, nobody
> else should change that name. If you do, you'll have no idea where/
> when the file came from, or be able to talk easily about it.
>
> I suggest a preference somewhere. "Keep all programmed times with
> replacement files?" with Always/ Never/ Ask Each Time/ Ask only if
> duration is different. Then everyone can have their cake and eat it
> too.
Rich Walsh
doesn't change the Loop Start Time if the file is the same length -
although it does change all the other times (I think)...
It wouldn't be too difficult to write a script to copy all the
settings from a cue, change the file target, and then paste all the
settings back again, particularly if Chris has a handy list of what
does get reset when you change the file target.
Rich
Christopher Ashworth
> Oddly, I've found that replacing a file target via a script command
> doesn't change the Loop Start Time if the file is the same length -
> although it does change all the other times (I think)...
Huh...that does seem odd. I haven't tested it yet, but I did double
check the code and scripting is setting the file through the same
mechanism that is used when setting the file any other way, so I'm not
sure what you're hitting there...
> It wouldn't be too difficult to write a script to copy all the
> settings from a cue, change the file target, and then paste all the
> settings back again, particularly if Chris has a handy list of what
> does get reset when you change the file target.
For audio cues, changing the file target will only change the start/
end times (and loopstart/loopend times) under the conditions
previously described. (Volume levels are not modified unless you do
it manually.)
-C
Rich Walsh
>> Oddly, I've found that replacing a file target via a script command
>> doesn't change the Loop Start Time if the file is the same length -
>> although it does change all the other times (I think)...
>
> Huh...that does seem odd. I haven't tested it yet, but I did double
> check the code and scripting is setting the file through the same
> mechanism that is used when setting the file any other way, so I'm
> not sure what you're hitting there...
It's stranger than that, actually: the contents of the Start Time are
put into the Loop Start Time field when you replace the file target,
with or without a script!
>> It wouldn't be too difficult to write a script to copy all the
>> settings from a cue, change the file target, and then paste all the
>> settings back again, particularly if Chris has a handy list of what
>> does get reset when you change the file target.
>
> For audio cues, changing the file target will only change the start/
> end times (and loopstart/loopend times) under the conditions
> previously described. (Volume levels are not modified unless you do
> it manually.)
This script will allow you to change the file target without losing
these times then:
tell application "QLab"
set theCue to last item of (selected of front workspace as list)
if q type of theCue is "Audio" then
set currentStart to start time of theCue
set currentLoopStart to loop start time of theCue
set currentLoopEnd to loop end time of theCue
set currentEnd to end time of theCue
set currentTarget to file target of theCue
tell application "System Events"
set whereToLook to POSIX path of container of (currentTarget as
alias)
end tell
set newTarget to choose file with prompt "Please select the new file
target:" default location (whereToLook as POSIX file) without invisibles
set file target of theCue to newTarget
set start time of theCue to currentStart
set loop start time of theCue to currentLoopStart
set loop end time of theCue to currentLoopEnd
set end time of theCue to currentEnd
end if
end tell
Rich
Christopher Ashworth
> On 21 Oct 2009, at 23:30, Christopher Ashworth wrote:
>>
>> Huh...that does seem odd. I haven't tested it yet, but I did
>> double check the code and scripting is setting the file through the
>> same mechanism that is used when setting the file any other way, so
>> I'm not sure what you're hitting there...
>
> It's stranger than that, actually: the contents of the Start Time
> are put into the Loop Start Time field when you replace the file
> target, with or without a script!
Ah ha! Now that there is a good old fashioned bug, and a tip o' that
hat to you for finding it. The code in question is doing this:
[self setEndTime:[NSNumber numberWithDouble:[_sound durationOfFile]]];
[self setLoopEndTime:[NSNumber numberWithDouble:[_sound
durationOfFile]]];
[self setLoopStartTime:[NSNumber numberWithDouble:0]];
[self setStartTime:[NSNumber numberWithDouble:0]];
When it should be doing this:
[self setEndTime:[NSNumber numberWithDouble:[_sound durationOfFile]]];
[self setLoopEndTime:[NSNumber numberWithDouble:[_sound
durationOfFile]]];
[self setStartTime:[NSNumber numberWithDouble:0]];
[self setLoopStartTime:[NSNumber numberWithDouble:0]];
In other words, the loop start time is constrained by the absolute
start time, so since QLab is setting the loop start time *first* it is
getting constrained to be the current absolute start time -- right
*before* that absolute start time is itself reset to zero.
This will be fixed in the next release.
Mr. Rich, for someone who hasn't been a QLab user very long, you sure
have been making your mark helping us improve the tool!
-C
Matt Otto
Matt Otto
(609) 707-2978
Off List: motto...@gmail.com
http://www.mattottosound.com
Matt Otto
I totally agree with Jeremy, even without working with a complete
music department. Just for myself I would really prefer to keep
original filenames to be able to identify what versions I'm currently
using.
I wouldn't neccesarily need all those options in preferences, but
having a little screen to ask me what to do (retain or reset timing)
would be lovely.
Michael Keniger
I would suggest "Replace File" where ALL cue settings are retained and "Replace Cue" which would replace the file and reset attributes (levels, pre/post, start/end and loop data).
Replace File would be the default behaviour.
Replace cue would be invoked either using a modifier key or keyboard shortcut. I wouldn't mind having a query box popping up asking which parameters I wanted to be reset (so levels could be retained but time values reset), but I know this offends some people!
Is there already a shortcut to reset timing data after a file has been replaced? - scriptable I suppose...
New Windows 7: Find the right PC for you. Learn more.
Christopher Ashworth
>
> Replace cue would be invoked either using a modifier key or keyboard
> shortcut. I wouldn't mind having a query box popping up asking
> which parameters I wanted to be reset (so levels could be retained
> but time values reset), but I know this offends some people!
There are already the buttons in the inspector to reset the levels on
a cue, so I think the focus here is mostly on the start/end times.
> Is there already a shortcut to reset timing data after a file has
> been replaced? - scriptable I suppose...
Yes, the arrow buttons next to the text fields will reset the timing
data to the defaults. (Zero and the length of the file.) Scripting
will also work, of course.
A general observation on the design of replacing times:
I don't deny that creating an option to "retain start/end times even
if the filename is different" would be genuinely helpful for the
people who have requested it. I think the use of a modifier key may
very well be a good way to implement this. The reason I am being
careful about it is that I need to also keep in mind the 99% of users
who are not on this mailing list and who are not served by this
feature. Back in version 1 QLab would retain start and end times even
when the filenames were different, and there is a reason it doesn't do
this anymore, which is not because I wanted to make the power users'
lives more difficult. :) It's because the majority of people were
not expecting this behavior and it caused problems for them.
So if I seem reluctant, it's not because I don't hear what you're
saying, it's just because I'm trying to balance your requests with the
silent voices for whom I must also advocate.
Cheers,
Chris
Matt Otto
false
luckydave
Do the things that please you, and do them well.
Jeremy Lee
The *only* times that I've wanted to have QLab automatically change
the start/ stop times of a cue was when I was given an audio file that
needed it's head chopped off, and then replaced it weeks later when I
had forgotten about that edit. The new file, if the start/ stop times
were retained, now did not play as intended, even if it played as
programmed.
I'm a strong advocate of something in the Applications Prefs that lets
you set a global method of working with this. But I also have another
suggestion- contextual icons.
It would be *fantastic* to have slightly different cue type icons to
indicate programming choices. An Audio cue icon would look different
if it loops or if the start/ stop time has been edited, or has an
integrated fade. A fade cue would look different if it's absolute or
relative. A MIDI cue would look different if it contains a CC Fade.
Etc. Is that a possibility?
I also can't stress enough how important I feel it is to have a dialog
box pop up when more than one cue will be affected by an edit. Like
when you drag an Audio cue on top of a group that contains fades, QLab
should ask you if you really mean to change all 50 fade cues to target
the Audio cue being dragged onto it. In the heat of battle, it's VERY
easy to "miss" when dragging a cue around the list. And a terrible
surprise when you do so and don't catch it...
Jeremy
On Oct 23, 2009, at 11:42 AM, false wrote:
> My vote goes to the option key while dragging if you want to lose
> the settings that are already there. If the new file is a different
> duration, then obviously end time, and perhaps loop time will have
> to be reset, otherwise, keep start times when possible by default. I
> like this idea.
--
Jeremy Lee
Sound Designer, NYC - USA 829
http://www.jjlee.com