Bundling again

[micpool]

I thought I understood everything about bundling, but in trying to track down disappearing surface masks when transferring between computers I have found that what I assumed, i.e that a bundled workspace looked for its files in the subfolders of the folder the open workspace is in  in, is not what happens.

I bundled a Video show onto a USB 3 flash drive This created a bundle folder with video and mask subfolders. I then copied the bundle folder  from the flash drive onto the hard drive of another computer. 

I opened the  show from the hard drive and assumed I was now referencing the files in the subfolders on the hard drive.But then I noticed that the light on my USB drive was flashing.

I opened the inspector and all the targets were still files on the USB flash drive. The surface masks were also referencing the files on the USB.

I closed the workspace, ejected the USB drive and reopened. The files referenced were now the files on the Hard drive. But the screen masks on the surfaces had disappeared, and there was no warning that they were not found. I assume that Qlab is using the absolute path for these masks and when it doesn't find them just blithely ignores the fact.

I think probably that my innate distrust of the bundling process has always meant that I have ejected the USB drive as soon as I have copied bundles over. It was only because I was trying to find my missing screen masks that I did not do so on this occasion but If these files are still referenced  then it seems rather dangerous and might explain some of the oddities that people have experienced with bundles. One likely scenario is that a bundle is copied and the USB is ejected but not physically removed. The computer is restarted, the forgotten ejected drive remounts  and then, without the designer or operator realising, the media is being played from the USB stick.

So in summary there are 2 main questions.

If the original drive is removed should the workspace find the surface masks in its own masks subfolder and am I correct in thinking there is a bug that prevents this?

If a workspace is opened in a copied bundle on a hard drive does it still use the files on the  drive it was copied from, if it is present and is this desirable?  

Mic

[Dave H.]

With a Basic Video license, it's not surface masks that disappear during the transfer process…the entire surface reference does.

Create a workspace with fullscreen video cues that appear on an external monitor.  Then, bundle the presentation to the desktop.

At this point, if this computer is connected to a different monitor, everything works perfectly, and I never even need to re-visit the Video preferences…QLab automatically reassigns the missing external surface to the new monitor.

However, if that folder is copied via a USB flash drive to a second computer (also running QLab 3.0.18 and the same version of OS X) with a different monitor, and the flash drive is ejected afterwards, two things happen:

- all video cues show as broken, with "no valid video surface assigned"

- the Video preferences shows two things:  a missing "Color LCD" (laptop monitor), which can be repatched to the current one below it, and the new external monitor.  The old external monitor does not appear at all…I always assumed that it automatically repatched it to the new one.

At this point, there's no choice but to go through each video cue and manually select the new external monitor from the drop down list.

I've never tried leaving the flash drive in place while launching it, but I will try that tomorrow when I'm at the aforementioned second computer.

[Joshua Langman]

"I then copied the bundle folder from the flash drive onto the hard drive of another computer."

I would have opened the show on the flash drive, and bundled it onto the hard drive of the computer, not just copied the folder. If you approach each move (from computer 1 to the flash drive, AND from the flash drive to computer 2) as a bundling operation, there tend to be fewer hiccups.

[Rich Walsh]

On 16 Apr 2014, at 22:45, Joshua Langman <jlangma...@gmail.com> wrote:

> "I then copied the bundle folder from the flash drive onto the hard drive of another computer."
>
> I would have opened the show on the flash drive, and bundled it onto the hard drive of the computer, not just copied the folder. If you approach each move (from computer 1 to the flash drive, AND from the flash drive to computer 2) as a bundling operation, there tend to be fewer hiccups.

That's unnecessary and could take ages to achieve with a big show. You DO need to make sure you eject the flash drive before opening the workspace on the second computer because, as Luckydave said on 21 March "QLab only references a relative file path if it can't find the files by their unique identifiers". The bundled workspace references the very files that are on the flash drive, and hence it will use them if they are available. A better workflow would be to bundle to computer 1 and then COPY that folder to your flash drive, which will create new unique identifiers: then when you open the workspace on any other computer it can never find the files it was originally referencing, only the local relative copies.

On 16 Apr 2014, at 20:56, micpool <m...@micpool.com> wrote:

> I thought I understood everything about bundling, but in trying to track down disappearing surface masks when transferring between computers I have found that what I assumed, i.e that a bundled workspace looked for its files in the subfolders of the folder the open workspace is in in, is not what happens.
>

> I bundled a Video show onto a USB 3 flash drive This created a bundle folder with video and mask subfolders. I then copied the bundle folder from the flash drive onto the hard drive of another computer.

>
> I opened the show from the hard drive and assumed I was now referencing the files in the subfolders on the hard drive.But then I noticed that the light on my USB drive was flashing.
>
> I opened the inspector and all the targets were still files on the USB flash drive. The surface masks were also referencing the files on the USB.
>
> I closed the workspace, ejected the USB drive and reopened. The files referenced were now the files on the Hard drive. But the screen masks on the surfaces had disappeared, and there was no warning that they were not found. I assume that Qlab is using the absolute path for these masks and when it doesn't find them just blithely ignores the fact.

That sounds like a bug.

> I think probably that my innate distrust of the bundling process has always meant that I have ejected the USB drive as soon as I have copied bundles over. It was only because I was trying to find my missing screen masks that I did not do so on this occasion but If these files are still referenced then it seems rather dangerous and might explain some of the oddities that people have experienced with bundles. One likely scenario is that a bundle is copied and the USB is ejected but not physically removed. The computer is restarted, the forgotten ejected drive remounts and then, without the designer or operator realising, the media is being played from the USB stick.
>
> So in summary there are 2 main questions.
>
> If the original drive is removed should the workspace find the surface masks in its own masks subfolder and am I correct in thinking there is a bug that prevents this?
>
> If a workspace is opened in a copied bundle on a hard drive does it still use the files on the drive it was copied from, if it is present and is this desirable?

See above. Basically you want to be sure that a workspace has to look for relative files because the files with the unique identifiers it knew about last time it was saved can not be found anywhere on the system – and the best way to make that happen is to only ever present copies of those files to the newly-housed workspace, never the files it has already met. "Absolute file paths" is not a relevant concept, as QLab can even find files in the Trash.

There is another bug here though: https://groups.google.com/d/msg/qlab/vydYMF9yYFI/RyFP_sfirNQJ – which suggests that the unique identifier of a file can persist (and be found) even when it has been overwritten…

Rich

[micpool]

Thanks Rich for your in depth reply. That all makes sense. 

I still think it would be better if Qlab always  looked first in the folder (and subfolders) the workspace resides in. Perhaps there is a good reason why this isn't the best idea?

I'm also trying to think through the other common workflow where I just copy the show folder across the network to the backup machine. Are there any circumstances where the backup might try and play files from the main computer across the network?

Mic

[Christopher Ashworth]

(mobile)

> On Apr 16, 2014, at 8:05 PM, micpool <m...@micpool.com> wrote:
>
> I still think it would be better if Qlab always looked first in the folder (and subfolders) the workspace resides in. Perhaps there is a good reason why this isn't the best idea?

Do you mean "look by file path first, ID second?"

[micpool]

I think I mean  file path relative  to the workspace.

Mic

[micpool]

Which would mean if I copied a folder from a USB to the hard drive and left the USB mounted, If I opened the workspace on the USB it would reference the files on the USB and if I opened the workspace in the folder copied to the hard drive it would reference the files on the hard drive.

Mic

[Christopher Ashworth]

That's interesting. I dig that. Maybe I'm missing some reason it would be a bad idea? But it seems like it could be a nice adjustment...

(mobile)

[El Armstrong]

Amen.  +1.  And infinity.  This is the behavior I have always expected - and seems the most Mac like (from my almost 30 years of Mac experience) to me.  On open, first priority would be the folder (or sub folders) the file is opened from.


 

micpool wrote:

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

[Christopher Ashworth]

(mobile)

> On Apr 16, 2014, at 10:08 PM, El Armstrong <news...@earthlink.net> wrote:
>
> Amen. +1. And infinity. This is the behavior I have always expected - and seems the most Mac like (from my almost 30 years of Mac experience) to me. On open, first priority would be the folder (or sub folders) the file is opened from.

To make sure, the complete description is that first priority is to the path relative to the location of the workspace, which may or may not be in the same folder or sub folders.

This distinction is important, because it's well-defined, whereas I don't currently know what the definition is for the above description ("first priority in the folder or sub-folders").

[El Armstrong]

Yes, the "path relative" is exactly what I meant. If my Qlab file is
"MyShow" in /user/showname, and the cue pointed to GoofyVid.mov in
/user/showname, then if a cue called /user/showname/GoofyVid.mov, it
would play that cue. If it pointed to
/user/showname/Video/GoofyVid.mov, it would ignore
/user/showname/GoofyVid.mov, and instead would play
/user/showname/Video/GoofyVid.mov. And /volume/usb1/GoofyVid.mov would
be right out. This allows me to move previous versions of a cue to a
"neutral" space, while only having the current version in the "active"
cue space. Does that clarify?

[El Armstrong]

And I just noticed the distinction that you are pointing out. If
"MyShow" in /user/showname has a cue that points to
/mysoundeffects/from_other_ sources/Cat_hack.aiff, I would not expect it
to link to a new location if I don't copy that relative location to the
new computer. This example is where bundling would be helpful.

[Rich Walsh]

On 17 Apr 2014, at 01:05, micpool <m...@micpool.com> wrote:

> I'm also trying to think through the other common workflow where I just copy the show folder across the network to the backup machine. Are there any circumstances where the backup might try and play files from the main computer across the network?

I've never had this happen, although I don't often actually open a workspace while the network drive on which it originated is still mounted. When I don't have a server (ie: not at the NT!), I make stuff on my laptop, Synkron that over to show machine 1 (which is file sharing) and open the workspace there. I then Synkron between the two show machines from my laptop: I very rarely mount one machine on the other – and if I do, I'll unmount that before opening the backup to check it works, as otherwise I'm not actually checking that the backup works in show conditions…

Anyway, I don't think it _can_ happen as I don't think unique identifiers are served over networks: file location is by url on a network volume. I suspect this is because the unique identifiers are not actually part of the file, but part of the HFS+ file system databases – all that stuff that Norton Disk Doctor used to tell you needed repairing every 5 minutes. Hence, they travel with local drives but not fileshares. However, I have not been able to find a definitive explanation of this with a popular search engine in 10 minutes this morning. So, that is all unconfirmed conjecture.

Just to be clear, we are talking about opening a workspace that was made on one computer on a new computer while the original assets are available to the new computer on a network volume, along with copies of those assets in a local nested folder with the workspace. We are not talking about adding files to a workspace from a network volume.

Rich

[Drew Schmidt]

Just to pipe in. I wonder if this is a really specific case problem and to structure order that way actually forces us into organizing our folder structure in a very specific way, meaning we need to learn how QLab thinks in order to use QLab efficiently rather than what Figure53 does so well, creating multiple avenues to handle how multiple artists conceive their art. 

I think I find problems with bundling only when I mess with the bundle after the fact. Seems to be a delicate thing. 

The real problem here is "fixing a boat load of broken cues". Yes? That's when we moan and groan.

What if the solution were a method of mass fixing / relocating.

• Relocate one broken file
• File structure WAS the same for all the other files (i.e. Bundling ... or a well organized designer) [i.e. /Desktop/Showname/Audio]. Workspace found on the desktop. 
  
• File structure CONTINUES to be the same, just a different root [i.e. /Desktop/2014/Showname/Audio], but the workspace is left on the desktop.
• I would expect QLab (and find this to be true with many other applications), that all other broken Cues with a similar folder structure change and in turn identical FileIDs would also be fixed. .... In other words, replace all files with a path beginning in "/Desktop/Showname/Audio" with "/Desktop/2014/Showname/Audio"

[Lucas Krech]

Several programs I use have this functionality and it is great from a user perspective.

-L

*insert witty mobile device advertising here*

[micpool]

On Thursday, April 17, 2014 1:03:34 PM UTC+1, Drew Schmidt wrote:
> Just to pipe in. I wonder if this is a really specific case problem and to structure order that way actually forces us into organizing our folder structure in a very specific way, meaning we need to learn how QLab thinks in order to use QLab efficiently rather than what Figure53 does so well, creating multiple avenues to handle how multiple artists conceive their art. 

I think you are misinterpreting the proposal. It really doesn't impose any structure and you can carry on being as disciplined or sloppy as you like with file locations.

All it does its make the first place the program looks for files the same folder as the workspace is sitting in. For people who are very disciplined in only adding material to workspaces after they have placed it in the show folder, or for users who bundle to consolidate their projects this would seem to be the best option and avoids the scenario where a workspace contains references to files in 2 locations when the designer believes all the files in use are in a single place. After that it works in exactly the same way it does at the moment.

>
> I think I find problems with bundling only when I mess with the bundle after the fact. Seems to be a delicate thing. 

Exactly, I rarely have problems with bundling but sometimes everyone seems to come across a situation where files,are not found or the files in use are not actually in the location expected. It shouldn't be a 'delicate thing' but a clearly and easily understood program feature that all users can be completely confident they understand fully.

>
> The real problem here is "fixing a boat load of broken cues". Yes? That's when we moan and groan.

Agreed. DAWs, video editing, 3D modelling, and all similar program's which require assetts used in projects to be immediately available usually have mechanisms available to fix large numbers of file paths in a single operation. Adobe After Effects is particularly good at this .

This is a completely separate issue though to the main point of discussion which doesn't involve an immediate problem with missing files and red x's but confusion over file location which means that adding files to a previously bundled workspace can result in a workspace using files fro 2 locations when the designer believes that all files are in one place or that cues are accidentally being replayed from media that it is intended as a conduit for file transfer e.g USB flash rather than a high performance device, e.g SSD..

Mic

[Andy Dolph]

That's what I thought when I read the discussion - and I'd add my vote
for that as a preferred behavior...

[micpool]

On Thursday, April 17, 2014 12:03:08 AM UTC+1, Rich Walsh wrote:

You DO need to make sure you eject the flash drive before opening the workspace on the second computer because, as Luckydave said on 21 March "QLab only references a relative file path if it can't find the files by their unique identifiers"

So for the sake of absolute clarity is this currently a once only deal. I.e I eject the flash drive before opening the program, it can't find the original identifiers so uses the relative paths to find the files in my copied folder and all is good with the world. Is this forever?

What happens if at some stage in the future the usb with the bundle I copied is reinserted in the machine. Will the workspace then go back to referencing the files on the USB the next time it is opened, or has the workspace at some stage saved the new file identifiers in the copied folder location.

Mic

[Chris Ashworth]

So for the sake of absolute clarity is this currently a once only deal. I.e I eject the flash drive before opening the program, it can't find the original identifiers so uses the relative paths to find the files in my copied folder and all is good with the world. Is this forever? 

The current behavior is:

If QLab can’t find the file by the ID, it looks at the last known relative path (relative to the workspace file).  

If it finds the file that way, it updates the ID for the file and henceforth continues to use the ID unless or until that fails, at which point it again uses the last known relative path.

The last known relative path is updated every time the workspace is saved.

-C

[Rich Walsh]

When you save the workspace it will store the new locations of its assets and then you will be OK to mount your flash drive again. So, it's forever as soon as you save the new workspace.

Rich

[El Armstrong]

Is this new file behavior in Qlab 3 only?  Because it has never worked that way for me in Qlab2.  I have to manually relink *every* file.  Makes it difficult/painful to do "offline" editing away from the theater.

Chris Ashworth wrote:

--

[Chris Ashworth]

All it does its make the first place the program looks for files the same folder as the workspace is sitting in.

I want to make sure it’s clear that this is not actually what it does:

Giving relative paths priority over file IDs does not have any bearing on whether the media files are in the same folder or sub-folder as the workspace file.  A relative path can point to a file outside the folder that contains the workspace file.

If it is better to design a rule which DOES account for whether the media is in the same folder we’d need to define exactly what that means.

-C

[Chris Ashworth]

Is this new file behavior in Qlab 3 only?  Because it has never worked that way for me in Qlab2.  

It was the same in QLab 2.

I have to manually relink *every* file.

Hm, I’m not sure what was happening there. It was the same process in v2, and in my tests, worked the same way.

-C

[Rich Walsh]

Sorry, but you're doing something wrong then! Offline editing is one of the best things about QLab. Most of my notes are done on trains and then uploaded to the venue. In over 4 years I've never had to relink anything.

Rich

[El Armstrong]

Hmm.    Well, here's my workflow - tell me if I'm doing something incorrectly.  Design show (Audio and Video)on my home machine/laptop.   Once the initial design is complete, bundle the show into a folder (named for the show) on my drive, and to a folder (named for the show) on a jump drive.   At the theater, open the show on the jump drive, and re-bundle to a folder (named for the show) at the root level of the show machine (this second bundle is the only way I have found to have all the files link up when the Qlab file is opened on the show machine).   Eject the jump drive and open the Qlab file.  Tech away, adding lighting and automation cues, etc etc.  

In my brain, I should be able to copy the Qlab file back to the location of the bundled file on my laptop and have it relink to the media there.  It doesn't.  I have to manually relink.  And again when I move the file back to the show machine.  So, instead, I bundle back and forth, which can take a substantial amount of time.

Thoughts on where I'm going wrong?

Rich Walsh wrote:

[Chris Ashworth]

In my brain, I should be able to copy the Qlab file back to the location of the bundled file on my laptop and have it relink to the media there.  

Are you copying just the workspace file from the show machine back to your laptop?

If so, yes, that would break. The workspace file on your show machine is looking for the files on the show machine, not your local machine. If the relative path structure for them is the same, then it *should* work, I think, but to be honest I’ve never tested that usage scenario.

The assumption is that once a workspace is opened and edited on one machine, moving it anywhere else is a process of moving the entire thing (with all media).  The workspace and the media files are treated as a whole, and trying to switch out just the workspace without dealing with the media files is not going to go well.

-C

[Rich Walsh]

I haven't got time right now to analyse El's workflow for a proper answer but I will say that my workflow essentially never uses bundles and always involves copying just the .cues file from computer to computer…

Rich

[El Armstrong]

Right.  Just the workspace file.  I do it all the time with After Effects, FCP, Isadora, etc.  As long as the media files stay in the relative path to the workspace, I don't have to relink.  That's how I expected Qlab to work as well.  

Even if Qlab would reconnect everything in a relative path after relinking one file, it would be helpful.    Copying several gigs of data back and forth all the time is a pain.

Obviously it's not a deal breaker for me - I've been using Qlab for several years, but, at the end of a 14 hour day, waiting another 20 minutes for all the media to copy is frustrating.

Chris Ashworth wrote:

--

[Chris Ashworth]

If you are organizing your files systematically, that should work, but it’s things like “I added a file on this machine and it doesn’t exist on this other one” which would quickly break things, and why we tend to think of bundling as the one true way to transfer between machines, since it ensures the files referenced by the workspace will exist on the new machine.

But, knowing you, I’m sure you are VERY systematic and thorough about file management, so normal rules don’t apply to Rich. :-)

[Chris Ashworth]

I think part of the problem with bundling is that I imagined it to be a rare thing, and it sounds like it’s extremely Not Rare.

(Well, at least with the people on this list, who are actually probably a terrible sample, and my guess is that with the vast majority of QLab users moving machines is still Extremely Rare.)

That said, if we adjust the priority of looking for files to use file paths first, and if that doesn’t screw something else up, that could make things more predictable, perhaps.

I’m still unclear as to why bundling seems to break so often for people here, as I’ve never had trouble with it. :-/

Anyway, I’m still interested in the discussion, because I don’t want moving workspaces to be a fragile process; predictability is important.

-C

[Rich Walsh]

Synkron. Or ChronoSync. Oh, and just put the files you use in the folder with the workspace: it really isn't that hard. Put the files you _may_ use in there too, even if you aren't using them yet. I wrote a script to gather media files years ago for when things have gotten really frantic and you just want to do a bit of housekeeping. Hmm, I might not have published that one though. Maybe QLab could do that for you instead of bundling; the script starts like this:

set theExplanation to "This script checks all the non-broken cues of the current QLab workspace for audio, video and MIDI files that are not in a subfolder " & ¬

"of the folder that houses the workspace. If any are found, they are copied to a folder of your choosing, and the cues are updated to reference the copies.

Files with the same name will be treated as if they are the same file: the first one will be copied, and all later cues will be updated to reference this new file."

Rich

[El Armstrong]

Sure, I would expect for that "added" file to not relink, but should it cause ALL the links not to work?

(and for the record, I'm pretty hyper about file management in my workspaces as well).

Chris Ashworth wrote:

[Chris Ashworth]

Sure, I would expect for that "added" file to not relink, but should it cause ALL the links not to work?

No, the other files should work, so really have no idea what’s happening in your workflow. :-/

-C

[Joshua Langman]

It's because of my uncertainty about exactly what happens with the file paths that I only ever move by bundling, never just copying the .cues file or even the entire folder. Yes, it takes a while, but I never have problems with files getting unlinked or cues linking to the wrong thing.

So to address Chris's point about the frequency of bundling, it happens at least twice a day while in tech (personal laptop to show computer and vice versa) and sometimes more.

[El Armstrong]

Every single show for me gets bundled and moved at least once.   I've never had a bundled file break, but it seems like a lot of flaming hoops to jump through for something that seems like it should be simple.  

Chris Ashworth wrote:

[Joshua Langman]

(And just a tip, in case anyone else finds this useful: I often start by building a show with the QLab file and all media in Dropbox, so I can access the same file in tech and outside of rehearsal and don't need to worry about moving anything. Obviously it's a terrible idea to run a show out of Dropbox, but this works well until maybe halfway through tech when all the media is bundled onto the show computer.)

[micpool]

I think we are talking about the same thing. I just expressed it sloppily.

Mic

[Nigel Hogg]

Re Chris's comment about frequncy of bundling, I certainly need to bundle regularly when rehearsing/ teching between the show and backup computer. I'm sure most people who use the set up of 2 mac mini's for reduntant backup have the same requirement. I suspect that's quite a lot of us!
Having said that, bundling is usually successful for me as long as I'm careful with copying, and always eject and remove the USB drive afterwards.

Nigel

[Chris Ashworth]

FWIW,

I would expect almost everyone on this mailing list has reason to bundle once or more for each show.

I would expect that almost everyone not on this mailing list creates and runs a show from one computer.

[Andrew Keister]

I have had the exact same issue El is reporting for several years, and I'm quite diligent in my file structure. The only way I've been able to reliably prevent a whole mess of broken links is to bundle, but this can be a huge pain/time waste when dealing with large shows. Mic's proposal as to how Qlab looks for "missing" files would be an excellent change IMO. Additionally (and perhaps later down the line) a "repair broken links" utility along the lines of a DAW or some of the other software already mentioned would be a most welcome addition.

--

Andrew

[Dave Tosti-Lane]

I'm not so sure about the second point Chris.

Since many designers work for companies that have computers installed in the booth or performance space, it's pretty common to take a show file away and work on it on a laptop. All my students do that here at Cornish - we have two QLab production computers, but most of the student designers do their initial build and a lot of their adjustments on their laptops, and then transfer over to the production computers. 

Since one of our spaces is also a union hall, they actually have to do this since it's not an option for them to sit at the computer in the booth or in the house and work on building and adjusting cues outside our tech rehearsal schedule.

Dave Tosti-Lane

[Chris Ashworth]

I'm not so sure about the second point Chris.

To be fair, I’m not sure about it either, but I think there’s a decent chance it’s true.

Since many designers work for companies that have computers installed in the booth or performance space

Note for example that many people who use QLab do not work for any company at all.

, it's pretty common to take a show file away and work on it on a laptop. All my students do that here at Cornish -

Which makes sense, since you’re training them for professional theater; my understanding is that many QLab users are not using the program in that context.

 we have two QLab production computers, but most of the student designers do their initial build and a lot of their adjustments on their laptops, and then transfer over to the production computers. 

Since one of our spaces is also a union hall, they actually have to do this since it's not an option for them to sit at the computer in the booth or in the house and work on building and adjusting cues outside our tech rehearsal schedule.

Again, I should stress I don’t currently have hard data on this, only anecdotal evidence based on watching our support stream, etc.

I’d liken it to the perspective held by most New Yorkers that New York is central to the theater world; from our perspective New York is a small slice of the theater / design / QLab usage in the world, and not particularly central.

{shrug}  

I could be wrong about the frequency of bundling, and it is perhaps a moot point if we can make the search for files work better for bundling and not effectively change for folks who don’t use bundling.

-C

[Joshua Langman]

(Not sure if this is helpful, but I'll just point to InDesign as another program that handles relinking assets really well. If you move all your linked files to a different folder and relink one of them, all the rest will take the hint and find themselves.)

[Rick Malone]

On the PC side, Show Cue System SCS will find all files after only one file is relinked.  That's assuming that all files are moved to the same folder.

On Thu, Apr 17, 2014 at 12:32 PM, Joshua Langman <jlangma...@gmail.com> wrote:

(Not sure if this is helpful, but I'll just point to InDesign as another program that handles relinking assets really well. If you move all your linked files to a different folder and relink one of them, all the rest will take the hint and find themselves.)

--

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

--

Rick Malone

Resident Sound Designer

The Classic Theatre of San Antonio
image001.png

[Chris Ashworth]

(Not sure if this is helpful, but I'll just point to InDesign as another program that handles relinking assets really well. If you move all your linked files to a different folder and relink one of them, all the rest will take the hint and find themselves.)

A nice behavior!  

To be clear, it’s not that I’m opposed to adding magic re-linking behavior, it’s just that to add it we need to figure out what it actually means to do it. :-)

Viewing it as a user from the outside doesn’t necessarily say much about what logic is being used on the inside, unless we also specify a lot more test cases e.g. when is Product X able to re-link, when does it fail, what choices does it make about when it decides it has found a file, etc.

Is it filename-based, hash-based, other?  What does it consider a “matching" file? Does it traverse folder hierarchies, and if so how far?  etc  etc etc

-C

[Dave Tosti-Lane]

We all make assumptions based on what we can see, true enough. For what it's worth, we don't really have difficulty doing the shift of show files without bundling. I stress to the students to set up their working folder in the same relative position on each computer, and to put all their working files under the same folder that their cues file is in. This seems to allow pretty easy transition from machine to machine. The most common problem we encounter is with the newbie, or forgetful oldbie, who adds a last minute wav or aiff directly from their thumb drive or remote drive without first transferring it to the appropriate place on the show computer. 

But, if all the audio files remain under that main folder with the cues file, we can just transfer the cues file back and forth without any problem linking.

[El Armstrong]

And that's what is not working for me.  Exact same folder/file structure on both machines - moving the cues file breaks all file links.

[El Armstrong]

Isadora does this quiet well - you might check with Mark Coniglio at Troikatronix about how it's handled.  Very nice guy, and very helpful.

[Rich Walsh]

On 17 Apr 2014, at 15:50, El Armstrong <news...@earthlink.net> wrote:

Hmm.    Well, here's my workflow - tell me if I'm doing something incorrectly.  Design show (Audio and Video)on my home machine/laptop.   Once the initial design is complete, bundle the show into a folder (named for the show) on my drive, and to a folder (named for the show) on a jump drive.

Why not just copy the bundle folder from your home drive onto the USB stick without opening the workspace, and then copy that to the show drive? That way the workspace never knows about the files on the USB stick and you've saved two bundling operations.

   At the theater, open the show on the jump drive, and re-bundle to a folder (named for the show) at the root level of the show machine (this second bundle is the only way I have found to have all the files link up when the Qlab file is opened on the show machine).  

I can't replicate that at all. Any variation I try, QLab will always locate the files that reside next to the workspace (ie: in the structure built by a bundle, or even in the same folder as the workspace) if it can't find the original files somewhere else on a mounted drive. I even used a FAT32 stick for the hell of it.

Eject the jump drive and open the Qlab file.  Tech away, adding lighting and automation cues, etc etc.  

In my brain, I should be able to copy the Qlab file back to the location of the bundled file on my laptop and have it relink to the media there.  It doesn't.  I have to manually relink.  And again when I move the file back to the show machine.  So, instead, I bundle back and forth, which can take a substantial amount of time.

This has always worked for me, and continues to work for me right now. Where does QLab think it last saw the file when the links come up as broken?

Thoughts on where I'm going wrong?

None, as I can not replicate this issue…

Rich

[James Mapes]

Resolume handles relinking well also. When you relink a file, it says "I see that there seem to be identical file names to other broken cues, here's a list of them, do you want to update them all?". The key, I think, is that it tells you what it will relink before it tries to magically relink things.

[Sam Kusnetz]

On April 18, 2014 at 5:01:44 PM, James Mapes (mapes...@gmail.com) wrote:

Resolume handles relinking well also. When you relink a file, it says "I see that there seem to be identical file names to other broken cues, here's a list of them, do you want to update them all?". The key, I think, is that it tells you what it will relink before it tries to magically relink things.

Seems to me the other key detail here is that it uses files names as its basis for matching.

sk

—

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

[James Mapes]

Certainly the ability to tell Cat_Video_3_Final.mov from Cat_Video_4.mov is pretty important to all of our workflows :-)

[Joshua Langman]

Doesn't QLab use file names as an identifier? I use this to my advantage as a way of replacing one file with another, by putting one file in the same place as an older file and giving it the same name. I really like the fact that it's replaced in QLab automatically. (Works in InDesign too.)

[Sam Kusnetz]

On April 18, 2014 at 5:27:06 PM, Joshua Langman (jlangma...@gmail.com) wrote:

Doesn't QLab use file names as an identifier? I use this to my advantage as a way of replacing one file with another, by putting one file in the same place as an older file and giving it the same name. I really like the fact that it's replaced in QLab automatically. (Works in InDesign too.)

Yes, but as Chris mentioned earlier, file name is not the *only* method that QLab uses, which is why you can move an audio file around on your hard disk or rename it without breaking any cues which reference it.

QLab connects to files via their unique ID first, and their filename second.

Cheerio

Sam

[Thomas Quinn]

I’m curious, as this is a bundling discussion… in Qlab 3 I’ve been transferring a show via bundle and noted a couple things, first mask don’t come along nicely…. someone already mentioned that, but I thought I’d chime in too, there’s also no evidence they’re not there… even the surface shows a file in the maxk, it’s just sometimes not applied, picking the file again resolves that… (even if it hasn’t moved)

and surface customizations don’t persist…. shutters, corner pins, that sort of thing, so moving a show, even bundled between design and production systems is an exercise in patience… not sure if anything can be done about the latter, but the former should be pretty simple…

I’m not in front of my show computer now, but I think I’m running beta 1 of 3.0.18 so these may have been fixed in the final release…it’s in show right now and running happily so I don’t want to disturb it...

just .02 for the pot…

Thanks!

------------------------------------
Tom Quinn
T...@battle4heaven.com
877-793-5175
www.battle4heaven.com

[Jeremy Lee]

Late to the game here, but thought I'd chime in anyway.

How I have been doing it for years with QLab 2 and now 3:

Create folder "ShowName" with subfolder "Audio Files".  Inside the Audio Files folder, create another subfolder "Pre-Tech Cues" (and any other organizational folders that make sense- cricket beds, pre show music, thunders, winds, etc all get their own subfolders)

Every day of tech/ previews/ etc gets it's own subfolder inside of "Audio Files".  So when I go to the apartment after tech, I create new cues that live there, and transfer the whole new folder to the show computer the next day.  Any edits to cues during rehearsal or tech go into that days folder on MY computer, then transferred over the network to the show computer.  Always sure to duplicate the files in the same place.  With an organized folder structure, this is easy.

At a lunch/ dinner/ end of day break, I save the QLab file on the show computer.  I then use command-D in the finder to duplicate it, and rename the newly created file with the date/ break name. I copy the duplicate QLab file to a "Backups" folder (in folder ShowName) on MY laptop, then move it to a Backups folder on the show computer.  I then copy the current show file onto my computer.

Every file and folder structure is identical on both machines, and this organization makes it easy to do so.  I never bundle shows, and never have to relink any files.  Here's an example folder structure that I use.

On Apr 17, 2014, at 10:55 AM, Chris Ashworth <ch...@figure53.com> wrote:

In my brain, I should be able to copy the Qlab file back to the location of the bundled file on my laptop and have it relink to the media there.  

Are you copying just the workspace file from the show machine back to your laptop?

If so, yes, that would break. The workspace file on your show machine is looking for the files on the show machine, not your local machine. If the relative path structure for them is the same, then it *should* work, I think, but to be honest I’ve never tested that usage scenario.

The assumption is that once a workspace is opened and edited on one machine, moving it anywhere else is a process of moving the entire thing (with all media).  The workspace and the media files are treated as a whole, and trying to switch out just the workspace without dealing with the media files is not going to go well.

--

Jeremy J Lee

Assistant Professor - Sound Design

College-Conservatory of Music

University of Cincinnati

jerem...@uc.edu

o: (513) 556-9597

c: (347) 276-9468