'replace as' file management changed in V3

[johng...@mac.com]

In Qlab2, SFX and LCS systems I've been able work on shows in a particular and speedy way that doesn't seem to work in Qlab3.

My usual method is to log into the show computer and access the audio file folder. When I do fixes on my computer to the cues audio files I just drag them into the 'audio' folder and do 'replace as'. As long as the file isn't loaded into the buffer this lets me do fixes in the background while rehearsal or shows are running without needing any programming.

But in Qlab3 this no longer works. After the file is dropped in, replacing the old file with 'replace as', I now get the old red x on the cue and have to retarget the cue to make the file work again.

Is there a way around this behaviour?

In Qlab2 you used to have a refresh button, can that be put back into the program?

thanks,

john gzowski

[Chris Ashworth]

In Qlab2, SFX and LCS systems I've been able work on shows in a particular and speedy way that doesn't seem to work in Qlab3.

My usual method is to log into the show computer and access the audio file folder. When I do fixes on my computer to the cues audio files I just drag them into the 'audio' folder and do 'replace as'. As long as the file isn't loaded into the buffer this lets me do fixes in the background while rehearsal or shows are running without needing any programming.

But in Qlab3 this no longer works. After the file is dropped in, replacing the old file with 'replace as', I now get the old red x on the cue and have to retarget the cue to make the file work again.

Is there a way around this behaviour?

Not currently, as we’re using a different file identification mechanism in QLab 3.

In Qlab2 you used to have a refresh button, can that be put back into the program?

I think the more likely option will be to change the precedence of how QLab looks for files, as per the discussion on the mailing list a week or two (or more?) back.

That discussion boiled down to:

It probably makes much more sense to look for files based on relative file path FIRST and unique id number SECOND.  

I’m hoping to explore this change for the big 3.1 update we’re trying to finish, so that testing it can be part of the testing of that release in general.

-C

[johng...@mac.com]

Sorry I missed the previous thread.

If you do change the file search method to file path first and ID number second, what would happen in the case of files that have been changed through 'replace as'?

In Qlab 2 this worked fine, though if the file was longer you had to tell Qlab to play the full length.

Or will this result in cues needing to be retargeted with each change?

I know that most designers prefer to drop in different versions and manually retarget, but I've found this method way faster and results in a cleaner folder of audio files when it comes time to archive shows, though bundling also cleans out older versions of cues. 

[Chris Ashworth]

Sorry I missed the previous thread.

No worries, this list gets a lot of email.

If you do change the file search method to file path first and ID number second, what would happen in the case of files that have been changed through 'replace as'?

In Qlab 2 this worked fine, though if the file was longer you had to tell Qlab to play the full length.

Or will this result in cues needing to be retargeted with each change?

To be honest I’m not really familiar with “replace as”, but if it does what I think it does I would expect QLab to pick up the new file.

-C

[micpool]

I am not seeing the problem that John has and I can do what he is getting red x's on.i.e replace files.  Although there is a bit of weirdness with waveform updating. I'll do the whole process although we don't get to a replace action till about half way through my sequence.

On my system using 3.0.18 on 10.8.5:

I load a file (Duration 8s) (screenshot SS1 attached)

I edit the file cutting off the second half 

I play the file again in Qlab

Qlab plays the edited file correctly (4s) BUT waveform is still that of old file, and cursor stops in old waveform at new end. (SS2)

I duplicate the cue in Qlab using copy and paste

The new cue has the correct waveform but displays it rather strangely (SS3)

I click on each of the cues a couple of times and the waveforms reset to the correct lengths. However the first cue still has the duration of the original waveform (8s) displayed (SS4)

I now think I am replicating John's workflow…….

I edit the file again, cutting it in half once more.

I save the file to a different physical disc using save as…

I then drag this file to the original location of the file and replace when prompted by the dialog 

No red x for me

File plays at the new edited length (2s) but waveform is still as it was on previous file (4s) and duration is still as original (8s) (SS5)

No amount of clicking will reset the waveform

Save and close the workspace

Reopen and waveforms and lengths are all correct  (SS6)

Mic

[johng...@mac.com]

Here's my work flow and my problem.

Running Qlab on theatre computer

logged in as user, working on my machine and doing screen share

On my machine, I'll fix a file in my DAW (digital performer) and drop the bounced wav file into the theatre Qlab/show/audio folder doing 'replace as'.

When I do that get a blank waveform display and the file won't play.

Workaround is to retarget the file in the theatre show Qlab file.

It works, but its added one more step and slowed down my work.

Up until now I could do fixes in the background while the sound op runs the show, dropping in files while the show is running or they are rehearsing sections.

Now I need to call the SM on com tell them sound is busy, call the op on com, tell him to take his hands off Qlab, do the retargeting (or ask them to do it) and then tell the op and SM that we're good to go.

During tech time that's slower.

I could also drop in different versions, but I still have to retarget cues.

Is there a big advantage to the new file identification method that I don't understand that makes it worth this change?

The red x problems seems to come and go, I'll check to see when I get it and report.

thanks

john gzowski

 

[micpool]

There seem to be some strange inconsistencies in what happens when you edit files that are targeted   in a cue list in Qlab3.

I can't get a reliable pattern to what is happening but I think there is a difference when you edit an existing file in an audio editor and when you bounce a new version out of a DAW replacing the old one.

I haven't seen any red xs But I have a workspace open where there are cues that have no target because the file is no longer present, and nothing in the waveform view, yet there are no red xs and a play symbol appears when the cues are triggered! Screenshots attached.

There also seems to be a problem with Qlab3 sometimes reporting files  in use when they are neither loaded or playing, resulting in failed file save as….file exists……replace operations

The attached screenshots together with  the 6 in my previous post demonstrate that there many manifestations of inconsistent updating and refreshing of file info and it is perfectly possible to have a workspace where the same file is targeted in a number of cues but the cues show different waveforms and durations to each other and to the actual contents of the targeted file.

I'm not sure all this is related to the file identification method either.

I  also spent a little time trying to work out the logic of what happened with markers, when files that had markers inserted in the DAW that had been modified in Qlab were then remixed in a DAW or edited in an audio editor and retargeted or replaced  but because of all the other inconsistencies, my head started hurting and I thought I'd save that until the simpler updating problems were clearer.

I have to say I haven't previously come across many of these problems in real life  because I've always versioned new mixes and edits with different file names and retargeted,  on the basis that it's a bit dangerous having multiple copies of an audio or video file with the same name, but completely different content scattered around the main machine, the DAW machine and any backups, quite apart from the disadvantages of  destructively editing the original file. But when John posted I had just installed Twisted Wave on my systems, which seems to  be a near perfect lightweight editor to use alongside Qlab3 and was editing destructively while I experimented with the combination of the 2 programs and was just becoming aware of some of these anomalies.

I also think that there were also problems and dangers in adopting a replace file and refresh  workflow with  Qlab2, , as there was often was a need to adjust start and end points, integrated fade envelopes, loops and other stuff when retargeting and refreshing files which I always found best to do at the time the cues were retargeted.

Mic

[johng...@mac.com]

Yes, there are some strange inconsistencies.

Replaced files show as blank, but if you retarget with the newly 'replaced as' version of the file it mostly seems to not update the waveform display, but no always.

I'm in the middle of a few shows, so don't have time to really test it, just trying to get the shows built. Just checked it now and it didn't give me the new cue length or waveform display. That means that every changed cue must now be brought in as a separate file and I hate that kind of mess in the show file system.

If I'm not nuts, it seems like the audio stays in the buffer when you do replace as, so that it plays back bits of the old version and the new version. If that's possible.

Will check on that, but its hard to do with a house full of actors and crew. 

Something odd also happens with the waveform display scroll bar. The scroll bar doesn't cover the bottom full range, so it looks like you should be able to scroll but its not possible. Zooming in and out seems to clear this eventually.

[johng...@mac.com]

Is there a way to clear buffers?

Qlab seems inconsistent in how long files stay in the buffer and as long as they are in the buffer 'copy and replace' doesn't work.

It use to be that just hitting escape would clear the buffer and then files could be updated, but now its less clear.

The 'load' function should highlight when an audio cue is loaded in the buffer, shouldn't it? And when you hit escape shouldn't that clear the buffer?

I'll poll around a few other designers to see if I'm the only one who works this way, but for me this requires finding a new way of working and file management.

It would be enough to request to do shows on Qlab 2.

I've already run into issues with SM's and directors having older macs and OS's, which means building a rehearsal version of the show on Qlab 2. 

Does a Qlab 3 license also allow you to run Qlab 2?

That would at least allow designers to choose which version you need for a show.

For instance, if you do nee mic inputs, effects or to run video you can use Qlab3, but if you don't you could request to use Qlab2?

Because I'm afraid to say, having now done about 4 shows on 3, given the choice I'd mostly prefer to still work on version 2.

[Sam Kusnetz]

Hello John

> Qlab seems inconsistent in how long files stay in the buffer and as
> long as they are in the buffer 'copy and replace' doesn't work.

While it may be true that there is room for improvement here, it's also
worth pointing out that the Mac OS is fairly opaque on the subject of
when a particular piece of information in RAM is deemed stale and either
ejected or shuffled to virtual memory. Part of the inconsistency that
you're experiencing may be related to that.

Chris has already stated that he intends to change how QLab looks for
files, and I believe that this will help. But also, I believe it's good
practice to avoid changing out a file that could be "open" in another
application.

> Does a Qlab 3 license also allow you to run Qlab 2?
> That would at least allow designers to choose which version you need
> for a show.

QLab 3 Pro Audio, Pro Video, and Pro Bundle license can be used with
QLab 2.3.9.

Basic Audio and Basic Video cannot.

> For instance, if you do nee mic inputs, effects or to run video you
> can use Qlab3, but if you don't you could request to use Qlab2?

Absolutely. And you don't even need to request it. You can just download
QLab 2 form our site and use it. You can even keep both versions of QLab
on the same computer, both activated at the same time.

> Because I'm afraid to say, having now done about 4 shows on 3, given
> the choice I'd mostly prefer to still work on version 2.

That is entirely your prerogative, although I do hope you'll take
another look at QLab 3 when we make the change to file management that
we've previously discussed.

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

[micpool]

On Sunday, May 18, 2014 8:57:15 PM UTC+1, johng...@mac.com wrote:

Does a Qlab 3 license also allow you to run Qlab 2?

Yes and no.

http://figure53.com/qlab/download/ 

says 

You can use your QLab 3 Pro Audio, Pro Video, or Pro Bundle license to unlock corresponding features in QLab 2.

Please note: QLab 2.3.9 does not support Basic Audio or Basic Video licenses.

I still think that its better if  each version of an audio or video file has a unique name, but having said that, I have seen a few designers have a hot key to call up a waveform editor, edit the audio and save it in the expectation that it will update in Qlab. Perhaps Chris will be able to tell us if there is something in the underlying Apple frameworks that means that this is not a good idea.

Mic

[johng...@mac.com]

 I do hope that the file reference method gets reworked, updating files without programming on a big show is a major time saver. I will regularly edit 10 or 20 cues and drop the fixes in, with QLab2, SFX and even the archaic LCS it all worked a charm. The files were fixed with no programming time (with the caveat that in QLab2 you have to tell the cue to play the full length of the file if it the new version was longer then the old version).

Its also good to know that I or the theatre can run version 2 with the pro license. I will make use of that certainly, and certainly your licensing plans helped kill SFX with their flexibility and understanding of scale of projects. Students and SM's being able to run shows for free until they need the extra feature is a great model.

I'll keep checking the updates, but at present will only version 3 if I need pitch change, effects or if the theatre doesn't have a digital board and I need sound card based mic cues until or if the file management system gets reworked.

thanks,

john

[Chris Ashworth]

I still think that its better if  each version of an audio or video file has a unique name, but having said that, I have seen a few designers have a hot key to call up a waveform editor, edit the audio and save it in the expectation that it will update in Qlab. Perhaps Chris will be able to tell us if there is something in the underlying Apple frameworks that means that this is not a good idea.

No, this is a reasonable thing to want to do; I’ll take a look at these kinds of refinements when I have a chance to sit down and do another pass at the file management stuff.

-C

[Chris Ashworth]

> Qlab seems inconsistent in how long files stay in the buffer and as
> long as they are in the buffer 'copy and replace' doesn't work.

While it may be true that there is room for improvement here, it's also
worth pointing out that the Mac OS is fairly opaque on the subject of
when a particular piece of information in RAM is deemed stale and either
ejected or shuffled to virtual memory. Part of the inconsistency that
you're experiencing may be related to that.

I don’t think it would be related to that since RAM paging to disk would only cause a delay as it is restored — the stored information itself would not change.

-C

[Chris Ashworth]

Is there a way to clear buffers?

Qlab seems inconsistent in how long files stay in the buffer 

If the yellow circle icon is visible, the file is buffered. (Although as Sam noted, it’s still possible to have the OS page RAM to disk. More RAM and fewer other open apps mediate that possibility.)

and as long as they are in the buffer 'copy and replace' doesn't work.

True; QLab isn’t looking for files to change out from underneath it once a file is buffered.

It use to be that just hitting escape would clear the buffer and then files could be updated

Stopping a cue (e.g. with escape) does clear the buffer, yes.

The 'load' function should highlight when an audio cue is loaded in the buffer, shouldn't it? 

Yes.

And when you hit escape shouldn't that clear the buffer?

Yes.

-C

[micpool]

I thought in the meantime a quick script could be made to force cues to refresh. The fact that this script doesn't work, may throw some more light on where the problem lies.

repeat with eachCue in (selected of front workspace as list)

set forcefiletarget to file target of eachCue

try

set file target of eachCue to forcefiletarget

end try

end repeat

What consistently happens when this script is triggered by a hot key after a file has been replaced is

1) Nothing

2) If the file is played and then the script is triggered the duration is set to the new file length but the waveform remains the same.

3) If the script is immediately triggered again the duration is set back to the old duration and the waveform still remains unchanged.

Mic

[micpool]

However if you put a dummy audio file somewhere, this script does work.

repeat with eachCue in (selected of front workspace as list)

set dummytarget to "Macintosh HD:Users:micpool:Desktop:dummy.wav" -- change this to locaiton of your dummy cue

set forcefiletarget to file target of eachCue

try

set file target of eachCue to dummytarget

set file target of eachCue to forcefiletarget

end try

end repeat

In doing this I think I found another minor bug. I made my dummy as a wav with 0 duration. A cue with a 0 duration file plays forever.

[Rich Walsh]

Clearing the file target with "set file target of eachCue to file missing value" before resetting it doesn't seem to help much either…

Have a blank waveform now.

Rich

[micpool]

I've now tested this on a couple of workspaces and it does seem quite a good fast  and viable solution. 

You would probably want to add a few refinements to it, like testing for audio cues and ensuring they are not playing when you run the script.

And of course you need to have the cues selected, so it's not so convenient for workspaces with multiple lists or lists with some groups collapsed and some not, where you want to keep them that way. Although you could probably script variations to cope with these eventualities.

As always test thoroughly before using on a real show file!

Mic

[micpool]

Actually the script does need to check it is only applying the refresh to audio cues otherwise some strange (and potentially catastrophic) things can happen.

The script should be something like:

set dummytarget to "Macintosh HD:Users:micpool:Desktop:dummy.wav" -- change this to locaiton of your dummy cue

repeat with eachCue in (selected of front workspace as list)

if q type of eachCue is "Audio" then

set forcefiletarget to file target of eachCue

try

set file target of eachCue to dummytarget

set file target of eachCue to forcefiletarget

end try

end if

end repeat

Also, this makes the Cue names behave as if they have been edited, so even if you haven't made a custom name for a cue (and the cue name is the filename as per settings) the name will not update if you retarget the file manually later.

There may be some other unexpected consequences so further testing IS  necessary.

Mic

[micpool]

One final update on this.

The script I have ended up with is:

set dummytarget to "Macintosh HD:Users:micpool:Desktop:dummy.wav" -- change this to location of your dummy cue

repeat with eachCue in (selected of front workspace as list)

if q type of eachCue is "Audio" then

set forcefiletarget to file target of eachCue

set file target of eachCue to dummytarget

set file target of eachCue to forcefiletarget

end if

end repeat

Actually the script does need to check it is only applying the refresh to audio cues otherwise some strange (and potentially catastrophic) things can happen.

 

This was a good idea anyway, but the reason it was potentially catastrophic was that applescript behaves differently to drag and drop with respect to group cues. Group cues do not retarget all audio cues when an audio cue is dragged on to a group (despite the dialog that pops up implying it will). But telling a group to set its target to an audio file through applescript does exactly that. In the case of this script all the audio cues in a group were immediately targeted to the dummy audio cue.

Similarly, a video cue can't be targeted to an audio file by normal methods like drag and drop or clicking the target selector button but scripting a video cue to target an audio file is possible.

The moral of this tale is that applescript will allow you to do things that the normal user interface will not, so you need to ensure that any applescript contains mechanisms that replicate the ways that the normal user interface protects you from yourself!

Also, this makes the Cue names behave as if they have been edited, so even if you haven't made a custom name for a cue (and the cue name is the filename as per settings) the name will not update if you retarget the file manually later.

This is incorrect. I thought the script  was causing this behaviour, but actually it's an 'opening a V2 workspace in V3 thing'. If you open a V2 workspace in V3 all the Cue names function as if they have been edited and don't automatically update when the file target is changed. 

 

There may be some other unexpected consequences so further testing IS  necessary.

Aren't there always. 

Mic 

 

[Chris Ashworth]

Hi John,

If I'm not nuts, it seems like the audio stays in the buffer when you do replace as, so that it plays back bits of the old version and the new version. If that's possible.

It does seem possible; if it’s just reading the file at that location and the file changes it may end up pulling values from the new file after it has exhausted buffered values from the old file. I haven’t had a chance to test it.

In general QLab is not currently expecting that files will change out from underneath it in the way you’re doing, so I am not surprised the results are odd.

-C

[johng...@mac.com]

On Tuesday, 20 May 2014 13:45:37 UTC-4, Christopher Ashworth wrote:

It does seem possible; if it’s just reading the file at that location and the file changes it may end up pulling values from the new file after it has exhausted buffered values from the old file. I haven’t had a chance to test it.

In general QLab is not currently expecting that files will change out from underneath it in the way you’re doing, so I am not surprised the results are odd.

-C

This may not be how you would expect the program to be used, but its been a great and super fast way for me to work up until now.

To be able to fix cues on my laptop and drop them in in the background while shows are rehearsing/teching/running is super powerful.

On big shows if you can drop in 20 or 30 fixes and not have to spend a second programming or taking half an hour of theatre time, that's big.

I've evolved this way of working over the last decade or so and have done a couple of hundred shows now.

Isn't it important to know how the program is being used in the field? 

[Andy Lang]

On Wed, May 21, 2014 at 6:39 AM, <johng...@mac.com> wrote:
> This may not be how you would expect the program to be used, but its been a
> great and super fast way for me to work up until now.

-snip-

> Isn't it important to know how the program is being used in the field?

It is indeed, and this is something we frequently acknowledge. As
Chris said, he and the rest of the dev team will look into this, and
try to make it work more easily in this situation in a future update.
He was merely explaining that, in it's current implementation, QLab
makes an assumption that does not work well for your use case.

We all agree that this would be a useful change, so we're going to see
what we can do about it. We can't promise exactly how soon it will
happen, but we hear you, and will do our best.

Best wishes from QLab Class in Stockholm,
Andy

[Christopher Ashworth]

(mobile)

In general QLab is not currently expecting that files will change out from underneath it in the way you’re doing, so I am not surprised the results are odd.

-C

[snip]

I've evolved this way of working over the last decade or so and have done a couple of hundred shows now.

Isn't it important to know how the program is being used in the field? 

Yes, very much so. Apologies that my email gave a different impression. My text above was just intended to be clear about how things currently work, not to say that the current way is best or most correct.

Cheers,

Chris 

[johng...@mac.com]

On Wednesday, 21 May 2014 09:10:11 UTC-4, Christopher Ashworth wrote:

Yes, very much so. Apologies that my email gave a different impression. My text above was just intended to be clear about how things currently work, not to say that the current way is best or most correct.

Cheers,

Chris 

Thanks Chris and Andy.

That's all I can ask for.

Forums like this are really a pretty great way for users and developers to be able to work together to help make the program the best possible. I'm always surprised by the different approaches people take and the different uses for the program. I know that there is no real one way to work and you must find ways to balance all of our needs as best you can. 

Good luck.

[Chris Ashworth]

Forums like this are really a pretty great way for users and developers to be able to work together to help make the program the best possible. I'm always surprised by the different approaches people take and the different uses for the program. I know that there is no real one way to work and you must find ways to balance all of our needs as best you can. 

Good luck.

Thanks, John. And I also appreciate the suggestions and feedback very much.  I know that sometimes on the developer side we can lose an important thread, or too-quickly brush off a good suggestion, and so we are grateful on our end for the thoroughness and generosity of everyone here helping us to make the product better.

Step by step, with a few stumbles here and there, forward we go.

-C

[Mark Valenzuela]

This might be a separate issue than the one dealt with in this thread, but it also might be related, so I thought I'd post as a reply.

I've noticed as I've been building a show with Q3 tonight (3.0.18 and OSX 10.9.3), that if I add an audio cue to a sequence, and then move the audio file to a different folder, that the cue will loose the target. If I restart the project, the target will still be lost. Additionally, if I first quit Qlab, then move the file, then re-open Qlab, it still does not find the file and will display a 'no target' red X. 

If memory serves, Q2 would find files if they were moved while the project was closed (I don't know if they would retarget if a file was moved while the project was open), and I thought Q3 did as well. I can recall a few times Chris' explanation to various inquiries about Qlab's ability to find a file if it has been moved by searching for the files unique id number. That function seems to not be working on my current set up. 

Sorry if this is a repeat question from recent threads. I know there have been some in reference to bundling, but don't remember seeing any with this specific issue. 

Any ideas?

Thanks,

Mark V.

-- 
-- 
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.

[Chris Ashworth]

Hi Mark,

I do think this may be related, yes. I’ve had trouble finding time to dig in to this stuff while away, but do plan to look at it all carefully soon.

-C

[johng...@mac.com]

Hey folks, its happy days now!

I'm not sure when you fixed the file management and haven't had time to post back here (too many shows and 12 hour days lately) but thank you guys so much for changing the behaviour.

I can now drop files in over wifi or ethernet into the Qlab audio folder and Qlab plays them without retargeting. You've even fixed it so that Qlab now uses the new file's length, so you don't need to adjust that in the programming.

These are great changes, you just sped up show changes a tonne for me.

Thank you very much.

john gzowski