dirkenstein Posted December 13, 2012 Posted December 13, 2012 Hi, Maybe I'm being daft, but is there any way to replace a linked cue in Magicq with a different cue? I can obviously update it with include/update.However, if I have a linked cue link-copied to, say, 5 places in a stack, is there any way to replace that linked cue with a completely different cue without re-copying to the 5 places? I can't find any way except performing and include, emptying the existing cue and manually recreating the content of the cue I want to use before update. Various other uses of copy, update and include don't seem to do what I want. Cheers, Dirk
indyld Posted December 13, 2012 Posted December 13, 2012 I don't see any quick fix around this although it's not something I've wanted to do. Offhand I can't remember what Record Replace options you have at this point in the workflow. If you want to edit (even to totally replace the values) a cue you are best to INCLUDE it whichever way. The only thing I would suggest is that making up a cue shouldn't take that long what with palettes etc. but if it does there is nothing to stop you creating a temporary scratch look which you can INCLUDE back into the Programmer when you need it. If you already have the cue somewhere then just INCLUDE it again. This just seems like a workflow issue really. Edit: So went to desk and basically: Include the Linked CueRemove all the heads in the programmer (or at least the data you don't want or block / unblock)Update. Works for me.
dirkenstein Posted December 13, 2012 Author Posted December 13, 2012 This just seems like a workflow issue really. Yup, the only viable method without remembering the cue values (no intensity palettes on this one) is something like: include original cue. Remove everything you don't want. Update. Include replacement cue. Include original cue, which doesn't clobber anything as it's now empty. Update. That works OK. Just didn't think of it under pressure yesterday- the trick is to nuke everything in the original cue. It was indeed a workflow issue. I've never wanted to do this before but I was trying to fix somebody else's cue stack. BTW additional slightly crazy workflow issue or idea: does anybody have any idea for way for how two people could work on a cue stack at the same time? I mean for somebody who's a 'runner' running the tail of the cue stack against a real rig during a rehearsal/tech and taking notes, making minor adjustments, whilst a 'fixer' is working blind against head of the cue stack or against the visualizer, according to notes from the 'runner' and/or director. Is it easy to merge two versions of a show, without causing complete chaos? I've never dared try.
indyld Posted December 13, 2012 Posted December 13, 2012 Yup, the only viable method without remembering the cue values (no intensity palettes on this one) is something like: include original cue. Remove everything you don't want. Update. Include replacement cue. Include original cue, which doesn't clobber anything as it's now empty. Update. That works OK. Am pretty sure that you don't need that many Updates. I simply included the original data, used Remove Head or similar to chuck it all out again and set up the look I wanted (or alternatively, Include data you do want) and the Update. As long as you don't do something that merges the Update it should be fine. As for multiple users editing all at once, this works for multi console setups all working on a centralised show file with zones, multiple stacks etc. but I'm not sure I'd try and edit a stack that was being played back elsewhere even if the editing either blind or just using a vis was actually any good (which, let's face it, isn't really good enough.) Merging show files together is fine for show admin time but is not something I'd consider while anything is actually happening. Sounds like a recipe for chaos in the cue stack. I guess that before considering such a solution to a problem, I'd want to analyse the problem in more detail. What needs to happen and why is it necessary? The reason for using multiple desks for programming is usually scale rather than problems with the programming further up the stack.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.