Best practice, multiple scenes or one?

gcld

Thank you. I think that my first approach was based on my background as a Lighting Designer, so I was thinking in cue structure. I am adjusted somewhat (show is up and file is working, so I'm not changing it now) and will adjust my approach in the future.

Thanks, Gregg

CitizenJoe

I'm also a lighting designer and I use Isadora in scenes in much the same way a lighting console organizes cues. It works for me! It also keeps the patches readable... When I want something that runs in multiple scenes with no change, I use Activate Scene.

Cheers,

Hugh

Michel

@gcld

I prefer scenes, especially when there are lots of changes/cues because its much more sorted. But performance wise there is not really a difference.

Best Michel

dbini

i tend to keep as much in the same scene as possible, and use envelopes to fade between different effects. Fades between scenes can sometimes produce unexpected results - particularly if you have video playing. the problem with this is that you could have processes running that don't need to be, and (particularly if you are using a lot of blur) the system starts to get stressed. you can solve this by putting different effects in Macros and switching them off when not needed (User Actor On/Off) or triggering the Bypass input of your heavier Actors.

if you are using the same actors, but with different settings in each scene, you could try working with Snapshots. (although its something I don't do, I know some of the advanced users are really into them) Another approach would be to use Trigger Value to change the settings. (or Envelope Generator++ to ramp from one setting to the next)

eight

I usually start with one scene, and then separate it into multiple (cue-based), so that whatever the complexity of the patch is, the technicians who are left with it, once I am done with the show, have to only press space bar on a cue, while checking their facebook page.

Maximortal

I tend to use different scenes as much as possible becouse during practice with actors is more simple to go through the show. If all it is inside a single scene you need to go around your workspace and manualy reset envelopes and so on...that is a waste of time if you are in hurry like always happen.

mwasser

It depends on the show. Using multiple scenes as "cues" makes it really easy to control from a lighting desk, or sync multiple computers. A show I'm working on now has a massive mix engine all in one scene, because the people running it need to be able to control anything anytime. Even for a one-scene show, I tend to put a "startup" scene at the beginning to get the patch open, input and output setup, etc. I do try and separate scenes out, but there are times when it doesn't make sense.

DusX

A dance show I just completed used a series of music files to structure the show.
These tracks played in sequence. In some cases, they were back to back and controlled automatically based on audio time.
In other cases there were unknown playtimes, and the cues were manually triggered/manipulated.

Each of these tracks/segments were Master Scenes with upto 3 sub sequences (to 5 projectors) being handled via 'activate scene' and tied to the Master tracks audio time (cool feature: I was able to scrub the audio and video sub-scenes together. Really great for rehearsal/tech).

So, basically I built a playback framework that supplied all the flexibility I required per segment/track, and then maintained a series of very simple scenes (in many cases only a movie player and projector).
This 'master' scene was duplicated for each track/segment.
I used a cue numbering scheme to keep it very organized (eg: Master 1.0, subA 1.1, subA 1.2, subA 1.3, subB 1.01, subB 1.02, subB 1.03, Master 2.0 etc....)

This framework needs another once over, but is basically now reusable. Its an example of what I am calling 'scene template' and is a functional mix multiple vs single scene approaches.

Woland

I have a general show template:

Starts with a projector test, mapping test, and hops over and activates a "CONTROLS" Scene containing the only Projector actors in the Patch.
Scene Template with the basic sets actors that I use over and over "Player>HSL adjust>FFGLPanSpinZoom>Broadcaster" (sometimes Crop and Flip too) + my Jump Actor setup.
- I copy this template for each cue in a production, and then set looks in the copies of the template.
- I often set multiple looks, and have different media for the same scene that I allow the director to choose from.
- I set these looks, take a snapshot, then set a different look, take a snapshot, etc.
  - "Oh, you don't like that water video? No worries, let me just cycle through the five (or more) other looks I have pre-programmed for each cue until we find one you like."

The Broadcaster actors (sending video) in the Scene Template are paired with Listener actors (receiving video) in the CONTROLS Scene.
- This means that all the video content comes from the Scene Template-based Scenes, and that it all gets routed to the CONTROLS Scene in order to use a single Projector actor for each display.
- This allows for quick and easy global mapping adjustments.
- This is an adaptation of a video-routing system designed by the ever-impressive @GertjanB .
The CONTROLS Scene also broadcasts its absolute Scene number, and each Scene Template listens for this and has an Enter Scene Trigger actor and an Activate Scene actor that activate the CONTROLS Scene upon entering any Scene Template-based Scene.
- I do this so that if I have to navigate to the CONTROLS Scene to do some programming or mapping adjustments, I can return to any Scene, as every Scene will re-activate the CONTROLS Scene.
When I need to use layers, I use 3D Projector actors (set to Render) and Virtual Stage actors in order to do all the layering in the Scene Template-based Scenes, and then use the Virtual Stage actor to send the layered video feed to the relevant, single Projector actors in the Controls Scene.

@dusx

I'd love to see that in action and/or dissect it to see what make it tick.

DusX

I will release the template here once I have had some time to clean up the logic (and a few edge cases that don't work exactly as I would like).