Don't bundle a workspace over the top of an existing bundled workspace

[Paul Gotch]

I learnt a very important fact last night.

If you bundle a workspace then bundle again and write it out over the
top of the current work space then the 'audio' folder gets deleted and
you end up with a broken workspace and no audio. I did this by
accident, it's not something you'd normally do.

In my normal paranoid way I had several other copies of the audio so it
was just a case of copying the folder back. However it may be good to
stop this behaviour so it doesn't bite anyone else.

-p
--
Paul Gotch
--------------------------------------------------------------------

[Chris Ashworth]

On May 8, 2012, at 8:42 AM, Paul Gotch wrote:

> However it may be good to stop this behaviour so it doesn't bite anyone else.

I'll take a look at making the protections stronger -- FWIW it does warn and ask for confirmation before proceeding, but since I can't think of a time when this is what you'd want to do, we should probably prevent it entirely.

Best,
Chris

[Paul Gotch]

Naively I would have expected it to add any new assets that were not bundled to the bundle...

-p

> --
> Change your preferences or unsubscribe here:
> http://groups.google.com/group/qlab
>
> Follow Figure 53 on Twitter: http://twitter.com/Figure53

[Alexander Taylor (Mailing List)]

Something along the lines of Consolidate Media Files in iTunes maybe?

Alexander

[ra byn (robin)]

Well, I certainly wouldn't expect Qlab to delete the audio in the folder
if the audio was in the folder to begin with. I would absolutely expect
any new assets that were not bundled already to be bundled...

ra byn

[Chris Ashworth]

On May 8, 2012, at 11:34 PM, ra byn (robin) wrote:

> Well, I certainly wouldn't expect Qlab to delete the audio in the folder
> if the audio was in the folder to begin with. I would absolutely expect
> any new assets that were not bundled already to be bundled...

Note that the warning message states:

"A file or folder with the same name already exists on the Desktop. Replacing it will overwrite its current contents."

[Paul Gotch]

On Wed, May 09, 2012 at 08:06:43AM -0400, Chris Ashworth wrote:
> "A file or folder with the same name already exists on the Desktop. Replacing it will overwrite its current contents."

Well I knew that in the back of my mind but didn't apply it to 'bundle'
because my mind associates that message with dragging things around in
the finder. I still think QLab should just refuse to do it full stop
given that unless there was a new 'rebundle' feature there is no
possible reason that the current behaviour is that you want to do.

[Rich Walsh]

On 9 May 2012, at 04:34, ra byn (robin) wrote:

> Well, I certainly wouldn't expect Qlab to delete the audio in the folder
> if the audio was in the folder to begin with. I would absolutely expect
> any new assets that were not bundled already to be bundled...

Hmm, but what about any audio that's already in the folder but is no longer in the workspace? What should QLab do with that?

For what it's worth, QLab is actually a lot more forgiving than SFX 5 was about hanging on to files: from my memory (I've been Windows-free for 2 years now), SFX would even lose its own cuelists if they weren't in _exactly_ the same place (including drive letter) on each machine. Memory like a - what are those things with holes in? This senility is probably what drove the mechanism for relinking, rather than some idealistic desire to provide tools for the end user. Ahem.

I don't get bundling. In order to copy the show backwards and forwards between the rehearsal room, the studio, my laptop and the two theatre systems I have to have all the audio in one folder - otherwise how do I make sure it's on every machine? Copying all 20GB of a show every time I make a change seems a little perverse to me: why not just copy the audio you're going to add to a workspace into the audio folder first? You'll never lose a file if you do this. Maybe it's having grown up using Pro Tools and the misery of trying to relink files using its clunky dialogues that just makes it appear so much easier to manage your content on ingest? I did actually write a script to do this, but I've never had course to use it: http://wiki.figure53.com/QLab+Scripts+and+Macros#x-General-Import%20files.

I only bundle on Press Night to compact the show for archive: back it up on another volume (using Synkron to copy just the changes), unmount that volume, bundle the show to the Desktop, quit QLab, delete the show, empty the trash, move the bundle into place, test it. Never lost a file in 2 years. Smug, or what?

Rich

[ra byn (robin)]

On Wed, May 9, 2012 7:06 am, Chris Ashworth wrote:
> "A file or folder with the same name already exists on the Desktop.
> Replacing it will overwrite its current contents."

Not enough & confusing because it doesn't make it clear you're about to
screw yourself by doing so.

----------------------------------------------------------------------------

"Anything in the bundle folder already will be deleted even if it should
be there after the bundle!!! DONT BUNDLE OVER AN EXISTING
BUNDLE!!!!!!!!!!!!!! Save as a new bundle."

Then not allow you to do it!!!

ra byn

[ra byn (robin)]

On Wed, May 9, 2012 8:11 am, Rich Walsh wrote:
> I don't get bundling. In order to copy the show backwards and forwards
> between the rehearsal room, the studio, my laptop and the two theatre
> systems I have to have all the audio in one folder - otherwise how do I
> make sure it's on every machine? Copying all 20GB of a show every time I
> make a change seems a little perverse to me: why not just copy the audio
> you're going to add to a workspace into the audio folder first? You'll
> never lose a file if you do this. Maybe it's having grown up using Pro
> Tools and the misery of trying to relink files using its clunky dialogues
> that just makes it appear so much easier to manage your content on ingest?

While I don't typically have more than a few gig of audio, I get the basic
workspace together. Bundle & backup.

Then I save the work space file with a new date & time (into the same
bundle folder) until I get to the point where I'm close or lots of audio
files have changed. If I feel like there has been enough changes to
possibly miss a file when I move to a different machine, I'll bundle
again.

It's not terribly difficult to make sure new / replacement files are put
in the bundle /audio folder but sometimes they don't get put in there.

At the very end of the rehearsal process, I'll do a final bundle to thin
out the herd & make the folder as portable as possible before I put it on
the other machines.

I've never seen the bundle warning because I've never considered bundling
over an existing bundle.

IF I did, I would want to be told NO before I was allowed to lose all my
audio & continue:)

For the same reason it should be difficult if not impossible to reformat
an OS HD while you're using the OS.

@ 2am after 12 hours of tech, warnings are always enough & certainly not
if they don't state the result very clearly of what will happen if you
ignore them.

My reading of the stated warning does NOT make me think I'm about to flush
any audio down the toilet. Instead I would think that any new audio will
be added to the old or replace the old with the same but new, etc...

I think I'll try saving a bundle over a bundle & see what sort of
emotional experience I have thru the process:)

ra byn

[Chris Ashworth]

FWIW I agree with Paul that this particular operation should simply be disallowed entirely.

Just pointing out that there is some reason to suspect QLab will delete the files in the folder.

-C

[ra byn (robin)]

On Wed, May 9, 2012 9:15 am, Chris Ashworth wrote:
> Just pointing out that there is some reason to suspect QLab will delete
> the files in the folder.

Chris,

If the warning you posted previously is all that Qlab says if you attempt
to bundle over an existing bundle, I would NOT be lead to believe I'm
about to delete my audio folder completely. Instead I would think that any
files needed to make the current workspace function will be included in
the new bundle.

If that means that files that are no longer used are deleted, of course.
If it means that files that are being used are about to be deleted, no???

I don't see how the current warning states that clearly & I can't think of
1 single situation where any one would want to delete all their audio
files.

But really, I also don't see why anyone would want to bundle over an
existing bundle. It's an easy way to cut your own throat (even without
losing your audio completely.

I clear house after the final rehearsal. Until then all bundles remain on
the HD just in case I need to go back to something which I've had to do
before. HD space is free & even if I had to make some room, I'd keep the
last few bundles & bundle to a new folder...

ra byn

[Jeremy Lee]

I only use it when a show comes back after a hiatus.  No need to have all my old versions of cues and such being carried forward to subsequent productions.  Break it down from a 20g folder to the 5g I actually used.  I have all the old stuff archived anyway if we need it.

On May 9, 2012, at 9:11 AM, Rich Walsh wrote:

I don't get bundling.

-- 

Jeremy Lee

    Sound Designer, NYC - USA 829

        http://www.jjlee.com

[mic pool]

So I have a new  high spec mac

MACPRO 2.4 8CX/6X1G/1TB/5770/S  with 2NVIDIA QUADRO 4000 FOR MAC  10.6.8 Latest Qlab

Its been in service for about a month and has done a couple of heavy video and sound shows. with hundreds of cues

The current show has about 40 simple sound cues and 1 video cue.

The video cue is run in the preshow check and a testcard is played on the output at the interval (the video cue is at the end of act 2)

The video cue ran for about 20 consecutive  rehearsals and performances perfectly.

In 2 of the last 3 shows the cue has started ,the audio has played but there has been no video output.

Re running the cue after the show has the same result.

Qlab is restarted and the cue plays fine.

Any ideas

Thanks

Mic

[mic pool]

Are there any known issues with wallclock triggers.

I have a bells project which has a cuelist with 4 cues which are triggered from the wallclock. at 3 hour intervals throughout the day.

Since the installation we have confirmed reports that cues have occasionally failed to trigger.

Anyone else come across this. A quick straw poll around a few sound guys this evening elicited a few other instances where it was suspected that wall clock triggers were not 100 percent reliable

As these are unattended installations in bell towers around the city is there any script cue we could put in a group with the trigger that would log the triggers

Thanks

Mic

[Chris Ashworth]

On May 16, 2012, at 7:25 PM, mic pool wrote:
> is there any script cue we could put in a group with the trigger that would log the triggers

I'm not myself aware of issues with wall clock triggers, but a bug is always a possibility.

From the terminal you can use the following command to enable extra logging:

defaults write com.figure53.QLab.2 LogLevel 3

Then logs will appear in Console.app

defaults write com.figure53.QLab.2 LogLevel 0

Will turn off the logging.

-CA

[Mike P]

By any chance do you play the cue and then fade the opacity to 0 without stopping it? I just ran into that one with similar results as you describe. Checking Autostop fixed my problem.



Mike Post
(601) 307-8657
mdp...@mac.com
http://mdpostdesign.com

[Rich Walsh]

On 17 May 2012, at 00:25, mic pool wrote:

is there any script cue we could put in a group with the trigger that would log the triggers

I'm quite fond of this form:

(* Log a message to the Console "All Messages" log *)

property userSender : "The sender" -- Use this variable to set the name that will appear as the "sender" of the message (for filtering the log)

property userMessage : "The message" -- Use this to set the message

logToConsole(userMessage)

-- Subroutines

on logToConsole(theMessage)

do shell script "syslog -s -k Facility com.apple.console -k Level notice -k Sender " & quoted form of userSender & " -k Message " & quoted form of theMessage

end logToConsole

You could simplify it, but I've used this as a subroutine in many a script now.

Rich

[Lucas Krech]

Checking Autostop fixed my problem.

Related, is there a way to globally Autostop all cues with opacity zero. That would be a really nifty thing to have as 9 times out of 10 I am fading to zero and never running the clip again. Or is it there and I am just captain oblivious?

Best,

-L

Lucas Benjaminh Krech

Lighting and Video Artist

www.lucaskrech.com

646.263.8439

gChat: lucaskrech

Twitter: lucaskrech

Skype: lucaskrech

- - - - - - - - - - - - - - - - - - - - - - -

"Don't tell me the moon is shining; show me the glint of light on broken glass."  

~Anton Chekhov

[mic pool]

No I checked that both of the test cues are terminated with stop cues rather than animaiton fades.

Thanks

Mic

[Dave "luckydave" Memory]

On Wednesday, May 16, 2012 at 7:45 PM, Lucas Krech wrote:

Checking Autostop fixed my problem.

Related, is there a way to globally Autostop all cues with opacity zero. That would be a really nifty thing to have as 9 times out of 10 I am fading to zero and never running the clip again. Or is it there and I am just captain oblivious?

On any animation or fade cue, check the "Stop target when done" box, and the cue will stop when the animation or fade completes.

-- 

luck...@figure53.com

 

[Lucas Krech]

I know it can be done individually. My question was as a global level or as a default setting. But I assume from your response that it can not.

-L

Lucas Benjaminh Krech

Lighting and Video Artist

www.lucaskrech.com

646.263.8439

gChat: lucaskrech

Twitter: lucaskrech

Skype: lucaskrech

- - - - - - - - - - - - - - - - - - - - - - -

"Processing seeks to ruin the careers of talented designers by tempting them away from their usual tools and into the world of programming and computing." ~Ben Fry

[dan howarth]

there's likely an easy scripted solution that queries running video cues for their opacity value and then stops cues that meet the specs .... this would amount to running a "clean-up cue" ... 

why not build-in the "stop target when done" business ??? are your cues fading down to zero and then back up, then back down ... before needing to be stopped ?? maybe

i like the global idea too but ... seems a bit unnecessary with the stop-target-when-done thing .. maybe

--

<theater...@gmail.com>

[Rich Walsh]

On 17 May 2012, at 06:12, dan howarth wrote:

> there's likely an easy scripted solution that queries running video cues for their opacity value and then stops cues that meet the specs

No, there isn't: an AppleScript query of a cue's properties does not report how they have been changed dynamically by other cues. In other words, a Video Cue's opacity is the opacity that appears in the Inspector when you click on that cue - not the cumulative effect of Animation Cues. It would be extremely difficult to try to figure out which Animation Cues have run at any given time and hence deduce all the active Video Cues whose _effective_ opacity is now 0. Much easier just to click on the handy box Chris has provided when fading out a cue once and for all...

Rich

[Chris Ashworth]

Hi Mic,

We're finding ourselves puzzled about this one. The behavior is similar to what can happen if the display got disconnected while QLab is running, but of course that isn't happening. (Or, that isn't described in your email.)

The long wait before the cue fires seems potentially related.

Has this been repeatable outside of show conditions?

Any chance there's a loose cable connection? (Unlikely, but looking for clues.)

-C

On May 16, 2012, at 7:16 PM, mic pool wrote:

>

[Lucas Krech]

 Much easier just to click on the handy box Chris has provided when fading out a cue once and for all…

Oh well. It's more a cover becuase programming can (for me) get sloppy when rushing new things in during tech. Feature for V.3?…

-L

Lucas Benjaminh Krech

Lighting and Video Artist

www.lucaskrech.com

646.263.8439

gChat: lucaskrech

Twitter: lucaskrech

Skype: lucaskrech

- - - - - - - - - - - - - - - - - - - - - - -

"Lighthouses are more helpful than churches."  

~Benjamin Franklin

[Rich Walsh]

On 17 May 2012, at 23:39, dan howarth wrote:

On Thu, May 17, 2012 at 1:36 AM, Rich Walsh <rich...@mac.com> wrote:

No, there isn't: an AppleScript query of a cue's properties does not report how they have been changed dynamically by other cues. In other words, a Video Cue's opacity is the opacity that appears in the Inspector when you click on that cue - not the cumulative effect of Animation Cues. It would be extremely difficult to try to figure out which Animation Cues have run at any given time and hence deduce all the active Video Cues whose _effective_ opacity is now 0. Much easier just to click on the handy box Chris has provided when fading out a cue once and for all...

thanks Rich for this and the clean-syntax of the if/then/else exercise --- also i did appreciate (with head-spinning and an empty-stomach) the two threads from 2009 ... more about all that if i can figure out how to use the script to send the playhead to the second audio cue .... (set playback position of theCueList to cue "12" .. doesn't get me there -yet-) ...

That probably depends on what "theCueList" is; this certainly works:

set playback position of first cue list whose q name is "Main Cue List" to cue "12"

This isn't a very fruitful, efficient or reliable course to pursue though. QLab already provides the objects needed to do if…then…else for all but the most exotic cue flow.

to clarify, a cue property such as opacity can be queried by applescript but the response will be .. the original value of the cue property as the workspace was most recently saved ? and that the response will not reflect any changes to the cue property which might have occurred since the most recent save ?? something like this ?? i was hoping that the response would be a little more "live" ie would reflect the data of the cue property at the moment of the running of the query ...... regardless of saving or animation / fade changes .. the response would be -- this is what the cue property's value is -right now- .......... does that make sense ? is there an easy answer to WHY the -right now- values can't be requested ? 

You've misunderstood: it's not about saving the workspace. It's about the fact that, say, the opacity of a Video Cue is a property of that Video Cue. The opacity being delivered to the outputs can be modified in real time by an Animation Cue (which has its own opacity property), but this does NOT change the opacity of the Video Cue itself. So, you can query the Video Cue as much as you like, but it will never be able to tell you anything about the current opacity being output – only its own opacity, which it will deliver when run.

Perhaps Chris can explain this better? In audio terms, it's like you can send audio and level commands into a mixer object and can query these level commands, but you can't talk directly to the mixer object about its current state – because it is not itself scriptable.

Rich

[dan howarth]

On Thu, May 17, 2012 at 1:36 AM, Rich Walsh <rich...@mac.com> wrote:

thanks Rich for this and the clean-syntax of the if/then/else exercise --- also i did appreciate (with head-spinning and an empty-stomach) the two threads from 2009 ... more about all that if i can figure out how to use the script to send the playhead to the second audio cue .... (set playback position of theCueList to cue "12" .. doesn't get me there -yet-) ...

[dan howarth]

You've misunderstood: it's not about saving the workspace. It's about the fact that, say, the opacity of a Video Cue is a property of that Video Cue. The opacity being delivered to the outputs can be modified in real time by an Animation Cue (which has its own opacity property), but this does NOT change the opacity of the Video Cue itself. So, you can query the Video Cue as much as you like, but it will never be able to tell you anything about the current opacity being output – only its own opacity, which it will deliver when run.

ok. thanks for the explanations ------ again to clarify: any / all modifications of cue property values happen as a .. one-way street ?? ie we hit GO and then we can't see -exactly- what is going on ?? this is getting into some kind of strange philosophy ? ... ie can we query the opacity of the animation cue that is changing the opacity of the video cue ? or because of, as you say, "the mixer object .. is not itself scriptable" -- there isn't anyway way to see the real-time values of things that are HAPPENING ? we can only see the original values before they were triggered ? 

[Jeremy Lee]

On May 17, 2012, at 11:43 PM, dan howarth wrote:

You've misunderstood: it's not about saving the workspace. It's about the fact that, say, the opacity of a Video Cue is a property of that Video Cue. The opacity being delivered to the outputs can be modified in real time by an Animation Cue (which has its own opacity property), but this does NOT change the opacity of the Video Cue itself. So, you can query the Video Cue as much as you like, but it will never be able to tell you anything about the current opacity being output – only its own opacity, which it will deliver when run.

ok. thanks for the explanations ------ again to clarify: any / all modifications of cue property values happen as a .. one-way street ?? ie we hit GO and then we can't see -exactly- what is going on ?? this is getting into some kind of strange philosophy ? ... ie can we query the opacity of the animation cue that is changing the opacity of the video cue ? or because of, as you say, "the mixer object .. is not itself scriptable" -- there isn't anyway way to see the real-time values of things that are HAPPENING ?

Nope.

we can only see the original values before they were triggered ? 

Yep. But, of course, your animation or fade cues obviously have durations and target end points.  It's not hard to guess what's going on.  If you need a cue that fades from -10dB to -20dB, but need a cue to fire at -15dB, then add a follow with an appropriate wait time.  Or split it into 2 fades that autofollow each other.

What are you trying to do that you're not able to?

[dan howarth]

what am i not able to do .... yeah .... i'm just trying to understand how all this works. the original question that got me going on this angle .. was from Lucas -- how to discern all -opacity at zero- cues .... and basically rich explained that this can't really happen because .. any real-time (animation cue, fade cue, script cue) changes are not visible to the scripting-engine, which can basically only see the original cue property values and not provide feedback about any real-time value-adjustments .. this jeremy has now echoed. thanks all. 

i'm driving this into the ground because of old lingering questions like --- why can't i ask -where in time- the playback is right now ?? i've learned a few sidesteps to that example, such as querying the pre-wait of a cue that is linked to the audio, or querying the duration of the audio cue itself ... however this kinda feels like the "guessing" just mentioned. 

in general- wouldn't it be helpful to have the qlab-engine tell us what the real-time values of cue property values ARE ? is there some sort of .. temporal threshold of observation ? ie when i asked the value was X but by the time the engine replies it's probably not X anymore (because it's being actively animated) .... this is that strange philosophy (heisenberg stuff almost eh). 

as you say, jeremy - it's not hard to guess what's going on. that's great for .. some situations .. and i appreciate your reply & query. i'm just wondering that having real-time feedback would allow a lot more to happen. ie, the original question from lucas, etc etc. i can imagine a lot of very useful variations to this sort of query: what has changed, what changes now = X, when # of changes = Z then do = Y .. etc etc .. 

perhaps this is getting outside the qlab ballpark ? again - thanks for the thoughtfully patient replies. 

--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

--

<theater...@gmail.com>

[dan howarth]

On Fri, May 18, 2012 at 10:24 AM, dan howarth <theater...@gmail.com> wrote:

what am i not able to do .... yeah .... i'm just trying to understand how all this works. the original question that got me going on this angle .. was from Lucas -- how to discern all -opacity at zero- cues .... and basically rich explained that this can't really happen because .. any real-time (animation cue, fade cue, script cue) changes are not visible to the scripting-engine, which can basically only see the original cue property values and not provide feedback about any real-time value-adjustments .. this jeremy has now echoed. thanks all. 

what if there was a way to UPDATE the cue property values AFTER the animation / fade / script has changed the values ?? this isn't real-time .. it's just updated-time .. 

[Lucas Krech]

in general- wouldn't it be helpful to have the qlab-engine tell us what the real-time values of cue property values ARE ?

Related, it would be wonderful if there were a load cue option which loaded the proper state of all other fades, cues etc. Say I have a sequence with a single background image and then several other images layered on top of it, I would love to just load the last cue before the GO so we are in the proper state ready to go rather than having to start at the beginning of the sequence and play through every single cue until we get there. Or is there a script for this?

Also, I would like to note that half my "questions" on this list seem to end up feature requests, and that overall I am very impressed with the software and want to give major kudos to Chris and the rest of the Figure53 team for making such a wonderful product.

-L

Lucas Benjaminh Krech

Lighting and Video Artist

www.lucaskrech.com

646.263.8439

gChat: lucaskrech

Twitter: lucaskrech

Skype: lucaskrech

- - - - - - - - - - - - - - - - - - - - - - -

"Dancers live in light like fish live in water"

~Jean Rosenthal

[Rich Walsh]

On 18 May 2012, at 18:27, dan howarth wrote:

> what if there was a way to UPDATE the cue property values AFTER the animation / fade / script has changed the values ?? this isn't real-time .. it's just updated-time ..

You already know these values because you can get them from the Animation or Fade Cue!

Rich

[Chris Ashworth]

On May 18, 2012, at 1:50 PM, Lucas Krech wrote:
>
> Related, it would be wonderful if there were a load cue option which loaded the proper state of all other fades, cues etc.

That's the way the load works, either using the Load Cue or the "Load to Time" slider on the workspace.

The key is to make sure you're loading from the top of the cue sequence. The load time will cascade down through all subsequent cues in the sequence.

> Say I have a sequence with a single background image and then several other images layered on top of it, I would love to just load the last cue before the GO so we are in the proper state ready to go rather than having to start at the beginning of the sequence and play through every single cue until we get there. Or is there a script for this?

No script necessary, just Load To Time.

>
> Also, I would like to note that half my "questions" on this list seem to end up feature requests, and that overall I am very impressed with the software and want to give major kudos to Chris and the rest of the Figure53 team for making such a wonderful product.

Ah shucks, thanks man. :-)

Always grateful to hear feedback and suggestions, that's how things get better.

-C

[Rich Walsh]

On 18 May 2012, at 18:50, Lucas Krech wrote:

Related, it would be wonderful if there were a load cue option which loaded the proper state of all other fades, cues etc. Say I have a sequence with a single background image and then several other images layered on top of it, I would love to just load the last cue before the GO so we are in the proper state ready to go rather than having to start at the beginning of the sequence and play through every single cue until we get there. Or is there a script for this?

We've discussed a number of times the reasons why this is incredibly difficult to achieve technically for all possible variations of a cue sequence. Essentially, how is QLab supposed to work out what state things are supposed to be in when the cues aren't in a sequence and can be fired at random? Realistically, can you even work it out every time without having to step through the cues?

I had a stab at writing something like this that more or less works for my way of programming (which doesn't include video):

http://wiki.figure53.com/QLab+Scripts+and+Macros#x-Loading-Jump%20into%20a%20string%20of%20cues

Rich

[Jeremy Lee]

Hmm.  In audio land, the only systems to do that are ones that emulate a traditional mixing console, ie LCS WildTracks.  But then you're limited to a mixing board paradigm- ie a limited number of available playback channels rather than "play as many as you want until you break it".

It's kind of the trade-off we make for the amazing flexibility we have with modern tools. I'm having a discussion on another list in which I would LOVE to know if a plug-in is clipping without the GUI open.  I only have one or two screens at a time, and potentially dozens of plugins on a session.  I just don't have enough screen real estate to have them open.  As the entire studio has shrunk into a laptop, some of that analog style feedback has gone away.  Maybe there's a way to get it back...

[Jeremy Lee]

I'm often adjusting levels on a cue after fades have taken place, and need it to stay where it was.  Maybe another pane is what you're looking for in the mixer window?

[Lucas Krech]

That's the way the load works, either using the Load Cue or the "Load to Time" slider on the workspace.

I mean for when the sequence is not a bunch of autofollows but rather a series of cues with manual GOs. That it can look at all the on/off states prior to the cue loaded and determine what should and should not be playing and at what level.  Or that this "load to time" function that I somehow missed?

-L

Lucas Benjaminh Krech

Lighting and Video Artist

www.lucaskrech.com

646.263.8439

gChat: lucaskrech

Twitter: lucaskrech

Skype: lucaskrech

- - - - - - - - - - - - - - - - - - - - - - -

"What I give form to in daylight is only one percent of what I have seen in darkness."  

~M.C. Escher

[Chris Ashworth]

On May 18, 2012, at 2:05 PM, Lucas Krech wrote:

>> That's the way the load works, either using the Load Cue or the "Load to Time" slider on the workspace.
>
> I mean for when the sequence is not a bunch of autofollows but rather a series of cues with manual GOs. That it can look at all the on/off states prior to the cue loaded and determine what should and should not be playing and at what level. Or that this "load to time" function that I somehow missed?

Ah, no you did not miss that.

In that case, the answer/discussion Rich just posted is a good summary of why that is very difficult (if not impossible) to do.

-C

[sam kusnetz]

> Lucas Krech <des...@lucaskrech.com> May 18 11:05AM -0700

>
> I mean for when the sequence is not a bunch of autofollows but rather a series of cues with manual GOs. That it can look at all the on/off states prior to the cue loaded and determine what should and should not be playing and at what level. Or that this "load to time" function that I somehow missed?

i think it's important to agree on some terminology here; the word "sequence" doesn't seem to mean the same thing to everyone.

i believe that when chris ashworth uses the word "sequence", he means a situation where a single GO triggers more than one line in a qlab cue list. is that right, chris?

a series of cues with manual GOs really isn't a "sequence" in this sense, because one of the great things about computer playback (qlab, sfx, and others) is that you don't need to go in order. i could fire the first cue, then skip a few, then fire the eighth, then jump back and fire the second. if that's the way i do it, how can there possibly be a load function that tracks all that?

i think a lot of people seem to conceptualize qlab as a timeline based tool, and it's really not. final cut pro, watchout, and pro tools are all timeline based, and so when you move the playhead to a specific time index, playback starts from that index "informed" of all the various state changes that precede that index. but qlab is non-linear. there really isn't the concept of a state change to the whole of a qlab system the way there is in a DAW. each cue is a independent event which has no causal relationship with any other cue, unless they're linked together with follows, or by being in a group, or by targeting (like a fade cue targeting a sound cue).

lucas: through careful use of follows and groups, i believe you can get what you're looking for. take some time to experiment with linking cues together and using the load to time slider to scrub to a time, then fire the cue and watch what happens.

dan wrote:
> in general- wouldn't it be helpful to have the qlab-engine tell us what the
> real-time values of cue property values ARE ?

would it? can you give an example of a real-world situation where that information cue be useful in the running of a show? i'm not trying to start a fight, i'm just trying to take this from the abstract to the specific.

cheerio
sam

--
sam kusnetz, sound & projection design | USA-829
503.201.2591
s...@notquite.net

[Chris Ashworth]

On May 19, 2012, at 3:37 AM, sam kusnetz wrote:
>
> i think it's important to agree on some terminology here; the word "sequence" doesn't seem to mean the same thing to everyone.
>
> i believe that when chris ashworth uses the word "sequence", he means a situation where a single GO triggers more than one line in a qlab cue list. is that right, chris?

That's correct; I should have taken a bit more time in my last reply to clarify that.

In QLab terminology, "cue sequence" is specifically a series of cues that are linked together from one GO using auto-continues or auto-follows.

> i think a lot of people seem to conceptualize qlab as a timeline based tool, and it's really not. final cut pro, watchout, and pro tools are all timeline based, and so when you move the playhead to a specific time index, playback starts from that index "informed" of all the various state changes that precede that index. but qlab is non-linear. there really isn't the concept of a state change to the whole of a qlab system the way there is in a DAW. each cue is a independent event which has no causal relationship with any other cue, unless they're linked together with follows, or by being in a group, or by targeting (like a fade cue targeting a sound cue).

This is a great description, and accurate.

I sometimes think of QLab, SFX, and related programs as being a collection of loose timelines. Cue sequences are timelines, but can be affected by cues in other unrelated timelines at unknown times. So the closest we get is a collection of "probable" timelines (cue sequences) that may or may not change based on other timelines that may or may not run.

Lucas, my understanding is that you have a lot of experience in the world of lighting (which is an area in which I have almost zero experience). My impression is that lighting has a much more constrained idea of "here is the sequence of state of all the lights, and it happens in this order, and we can jump backward or forward deterministically". I wonder if this may color or influence the thinking with which lighting designers approach QLab?

>> in general- wouldn't it be helpful to have the qlab-engine tell us what the
>> real-time values of cue property values ARE ?
>
> would it? can you give an example of a real-world situation where that information cue be useful in the running of a show?

QLab is certainly biased toward the creation of a "pre-packaged" design, rather than live modification of the show by the operator. I'd imagine that there are use cases in the latter that benefit from direct access and manipulation of live values. (e.g. DJ/VJ tools)

-C

[Mike P]

>
> This is a great description, and accurate.
>
> I sometimes think of QLab, SFX, and related programs as being a collection of loose timelines. Cue sequences are timelines, but can be affected by cues in other unrelated timelines at unknown times. So the closest we get is a collection of "probable" timelines (cue sequences) that may or may not change based on other timelines that may or may not run.
>
> Lucas, my understanding is that you have a lot of experience in the world of lighting (which is an area in which I have almost zero experience). My impression is that lighting has a much more constrained idea of "here is the sequence of state of all the lights, and it happens in this order, and we can jump backward or forward deterministically". I wonder if this may color or influence the thinking with which lighting designers approach QLab?

Interesting comments. I'm primarily an LD with a 'classic' background in computer programming (pre Object Oriented) and had the comment tossed in grad school at me in grad school that I'm a Linear Thinker instead of Associative. I was offended at the time since it implied I was less creative, but it made sense given my background.

I do tend to program QLab in a linear fashion, but don't think of it as linear in function. It still represents a series of steps towards a goal, but many of those steps overlap as they are executing. In other words, you start the storm bed and it plays continuously while you pepper it with thunder and gusts of wind on cue. The series of steps to make that happen are still linear but the result is a rich layered soundscape. Same sort of thing for Video (thank heavens for Alpha...) I even create 'subroutines' for video loops in separate cue lists to have a shorter clip that doesn't loop well blend with dissolves. So it plays as my 'bed' and I layer alpha on top of it.

We do this in light as well, but think of it less because the programming paradigms grew up in a more 'classic' realm of computers. Early consoles simply recorded a 'preset' for the lights for each cue. Sometimes the particular intensities of light don't change, but the values must be recorded in each cue regardless. Oddly enough, this was counter to manual operation which would allow for presets as a convenience to change entire looks, but you could always tweak an individual slider to change the content of the look. But it's what computers could do at the time.

At some point in the past (1980s?) these was a new concept brought about called 'tracking.' This meant that a cue would only store _changes_ in the values instead of the total state, thereby making light more 4-dimensional in operation instead of going from one state to the next.

To this day, tracking is difficult for many designers and some prefer to work 'Q-Only,' saving the state for each cue. However, the real power of tracking is not in economy of memory, but in the same layering of change over time that sound has. In other words, consoles have the capability of executing multiple cues so that one cue can be doing a 10 minute sunset fade on the cyc while others are shifting focus around the stage. Effects can track (random lightning for the storm) while the mood shifts in color. Things like that.

It's interesting to me that Lighting has a much longer history of computerized control than Sound and Video, but has a bit of a problem in letting go of the past :-)

[Lucas Krech]

Apologies for the improper use of "sequence" I was using it as a generic term for a seies of cues/state changes.

Yes my assumption was for linear playback. I'm not sure I would use QLab for a more open ended non-linear situation even if it can be used as such. But that is my prejudice. I do work in non-linear and improvised situations but they are far and away the minority so thank you for pointing out a bias I was unaware of in my looking at the software. 

As for the theatrical lighting bias that is certainly present. Though I would like lighting software as well to be able to understand being in the midst of a sequence of cues as well in that way like something such as FCP.

Best,

-L

Lucas Benjaminh Krech

Lighting and Video Artist

www.lucaskrech.com

646.263.8439

gChat: lucaskrech

Twitter: lucaskrech

Skype: lucaskrech

- - - - - - - - - - - - - - - - - - - - - - -

"I think it's essential for artists to have a seat at the table for determining the future trajectory of technology" ~Golan Levin 

[Lucas Krech]

Not to be too geeky about it, but tracking really is a return to the manual preset style where you only notate changes in state on your track sheets. ;-)

I would not consider overlapping cues to be non-linear. From a lighting perspective I would see linear vs. non-linear  as the difference between theatrical cueing and concert lighting. In a theatrical setting where you have a series of cues that run in order (but may overlap) and the order of playback is, without significant intervention, the same every night. Concert lighting is non-linear in the sense that you will have a cue stack for movement, one for color, one for patterns, effects, etc. Playback, rather than being a sequence of GOs is more about "Group 5 goto cue 3 on stack 4, goto cue 7 on stack 3, etc." 

Why this doesn't really work with Qlab (though perhaps there is a way to program around it) is that there is no inherent way to stop old media when you load new media. If I am in cue 5 and want to go to cue 3 I would also need to go to a cue that stops/fades cue 5. But I may not want to this all the time. Perhaps I decide in the moment that I want both cues to play on top of each other. AFAIK QLab does not truly allow for this. Given that limitation I would personally be wary of using it in a non-linear setting.

Quartz Composer, for example, with a simple MIDI interface, allows you to swap clips, combine clips, and add effects on the fly in whatever order you so choose. You do not run into the kinds of memory problems that QLab can have b/c it stops playing invisible media. Your computer is only processing the media that is being displayed.

-L

Lucas Benjaminh Krech

Lighting and Video Artist

www.lucaskrech.com

646.263.8439

gChat: lucaskrech

Twitter: lucaskrech

Skype: lucaskrech

- - - - - - - - - - - - - - - - - - - - - - -

"Processing seeks to ruin the careers of talented designers by tempting them away from their usual tools and into the world of programming and computing." ~Ben Fry

[Mike P]

On May 19, 2012, at 12:24 PM, Lucas Krech wrote:

> Not to be too geeky about it, but tracking really is a return to the manual preset style where you only notate changes in state on your track sheets. ;-)

Exactly :-) Except I don't have to ask my operator to track a 10 minute sunset one tiny little tweak of the faders at a time...

> I would not consider overlapping cues to be non-linear. From a lighting perspective I would see linear vs. non-linear as the difference between theatrical cueing and concert lighting. In a theatrical setting where you have a series of cues that run in order (but may overlap) and the order of playback is, without significant intervention, the same every night. Concert lighting is non-linear in the sense that you will have a cue stack for movement, one for color, one for patterns, effects, etc. Playback, rather than being a sequence of GOs is more about "Group 5 goto cue 3 on stack 4, goto cue 7 on stack 3, etc."

I confess, I'm not a busker. It's my main challenge with operating certain consoles which are configured for that purpose.

> Why this doesn't really work with Qlab (though perhaps there is a way to program around it) is that there is no inherent way to stop old media when you load new media. If I am in cue 5 and want to go to cue 3 I would also need to go to a cue that stops/fades cue 5. But I may not want to this all the time. Perhaps I decide in the moment that I want both cues to play on top of each other. AFAIK QLab does not truly allow for this. Given that limitation I would personally be wary of using it in a non-linear setting.

I'm a little confused here. I layer video all the time. Either I'm placing something with an alpha channel on a background or I'm letting a new clip layer over the top of the current one with the intent of returning to the previous. That way I don't have to stop and restart things. Most of what I do has at least a 'vignette' around the border to soften the edges. This executes as a PNG on the top layer at the beginning of show and just hangs out. Other cues are on layer 998 and play under the vignette.

[Mike P]

>
> Quartz Composer, for example, with a simple MIDI interface, allows you to swap clips, combine clips, and add effects on the fly in whatever order you so choose. You do not run into the kinds of memory problems that QLab can have b/c it stops playing invisible media. Your computer is only processing the media that is being displayed.

Ah - never mind. you're talking about overhead with layering. I do spend quite a bit of time playing with formats to keep things running smoothly. Question: If a clip is playing and stops because another clip hides it, when the second clip is removed, does the first clip pick up where it left off, or is there some way QC can track where it should be in time?

[Brendan Aanes]

Well, while I use Qlab for linear performances (am thrilled at what i can do), there's one situation that is not-necessarily-linear: rehearsing those performances. Enhancements to help this process would be very welcome.

I find Load-to-time to be unreliable with groups containing lots of groups and subgroups - sometimes it doesn't work with a given cue, and sometimes it does.

One idea would be a quickstep mode - like what is found in some lighting consoles - where, once enabled, the fade times on cues would be ignored and everything would execute instantaneously or in 3 seconds, so that we could more quickly get where we need to go.

Simultaneously, I am learning how to create the workspace so this is less troublesome (not using relative fades unless I have to, color-coding the beginning of a "block" of cues so the SM can know where to start), and also training the directors and stage managers around me to have patience with the intricacies of a complex design, since these tools are still relatively new.

[Chris Ashworth]

On May 19, 2012, at 2:56 PM, Brendan Aanes wrote:
>
> I find Load-to-time to be unreliable with groups containing lots of groups and subgroups - sometimes it doesn't work with a given cue, and sometimes it does.

If it is not working, this is a bug and I would welcome instructions on recreating it.

Cheers,
C

[Lucas Krech]

It would depend on how you programmed QC. Something like Isadora may be best for maximum control in a non-lienear situation. But what a F***ing nightmare when you need an ordered cue stack! It's more about the right tool for the right job. QLab is fantastic for linear theatrical style shows.

-L

Lucas Benjaminh Krech

Lighting and Video Artist

www.lucaskrech.com

646.263.8439

gChat: lucaskrech

Twitter: lucaskrech

Skype: lucaskrech

- - - - - - - - - - - - - - - - - - - - - - -

"Dancers live in light like fish live in water"

~Jean Rosenthal

[Jeremy Lee]

We talked about this not too long on here. Not in front of QLab right now, but I think if you make a fire all group, and inside are 2 more fire all groups, then you cannot load to time. The internal groups themselves have no 'time' and so load to time on the master group doesn't work. If you add a post wait without it continuing, then you can load to time up to the wait time.

Jeremy Lee
- A thumb is a terrible speller. Please forgive my trespasses.