Live performance & theatre

[sagerian]

Hi,

I'm a tech for a touring live show and I've been looking around for a timing system.

I just wanted to make myself know around here. I can't write any code beyond some simple Applescript but I may be able to contribute to this project in other ways. I'd like to see this project succeed because I feel it can bring a tremendous amount to the table.

Ontime has a number of great features that I would use on other shows, however it doesn't quite work for my current show. Ontime clearly shows a lot of potential.

I would like to be able to reduce the workload for staff (SM mainly) by automatically recording when Act 1, Interval, and Act 2 start/end. This information could be used to automatically populate the post show report template. In my situation qlab could easily send an OSC signal to ontime to start the timers.

Currently we use a hacky method of timing the interval with midi time code (MTC). QLab starts a MTC cue at 00:00:00 and stops after 20 minutes. The timecode starts along with the cue that is fired as the intermission starts so it's perfectly accurate for our purposes.

I've written a script that auto opens timecode window allowing front of house and other staff to see the time if they are within arms reach of the QLab MacBook. I would love a way for SM, FOH, Venue staff to easily see the interval timer on their phone (or apple watch?) instead.

I've been playing with the cuesheet display and I'd like to see some more columns

• scheduled start/end, and actual start/end
• scheduled duration, and actual duration

General features that would be nice

• An OSC command to move the cursor to a specific event and play immediately (there may be a way to do this already) I feel a bit uneasy about relying on where the cursor may or may not be in the events list and would like an option to ensure that when the first cue of Act 1 is started it definitely starts the ontime event Act 1 even if the cursor is in the wrong spot when the play command is sent.
• Option to have start time only. Oour showcall is 5:30 but it doesn't have a scheduled end. It's over when you leave the venue for the night. For comparison, our interval will have a specific end time as it is crucial we don't go over the 20 minutes. In this example the end time would be decided by when the interval start is played.
• Option to start some events manually and others automatically (show call is always 5:30 and could be auto, show start depends on a billion factors and would be triggered by QLab)

Bit of a ramble here happy to clarify if there's interest.

Thanks

[cpvalente]

Hey @sagerian, apologies it took me a while to get back to you. I wanted to have a good read since there are lots to unpack

First of all, thank you for your message and for getting involved. I have been developing ontime in collaboration with people like you and being able to do some feature testing and validaton of workflows is a great contribution.
I usually tend to prioritise issues that unlock a complete workflow rather than single actions like "add a button there".
Your input is very welcomed especially since there are not so many people from theater background working with ontime (to my best knowledge)

Onto your points

I've been playing with the cuesheet display and I'd like to see some more columns

scheduled start/end, and actual start/end
scheduled duration, and actual duration

Do I understand correctly that actual start / end would be a record of when did the operator started the running event and actual end when the playback moved away from this event? (which would mean that duration is a factor of the two).
This sounds like a good idea, but currently this data does not exist anywhere. I would however be keen on implementing

An OSC command to move the cursor to a specific event and play immediately
Currently you would need to create two messages to be able to do this
/ontime/gotoid id-of-the-event
/ontime/play
I never seen it as a problem since you can easily sequence this in a controller. What do you think?
I always imagined that ontime would be remotely controlled by a show control or control surface, so I will support any necessary developments in the API

Option to have start time only
There is issue #59 describing a similar function with different use case. This is something I am working on but need help fleshing out the behaviour as I fear it could break some current workflows.

• what is the duration of an event with just start? is it extrapolated from the next event start in which case it becomes just a shortcut to ease time entries?
• what happens to roll mode? if the event doesnt have an end, when do we consider it finished?

Option to start some events manually and others automatically
There are is some automation development in #55 to start an event after the previous or something similar. But I understand that the feature would be that some events would start at a fixed time while others would wait for a user input, is this right?
In which case, what happens to roll mode? Does this deprecates it in favour of manual / automatic events?

Thank you again for getting involved. It would be great to talk about your workflow and how could the app help you in the theater. Lets continue the conversation and maybe make some issues from here, feel also free to reach out at [email protected]

[abhibeckert]

Just adding a bit more context to this - around the start and end of an act, there is a lot going on for the stage manager.

On a large production there could be dozens or even close to a hundred people who all need to do something at exactly the right second, in completely different rooms, floor levels, sometimes different buildings. Even a simple performance there's a lot to do.

The workload then is 100x higher than at any other point in the performance and you rarely have enough people. If you did, 90% of them would spend the next hour doing nothing at all.

Even when it goes smoothly I often just glance at my watch at the start and memorise the time, then start my timer a minute (or five minutes) later and scribble it in my notepad. It's obviously not accurate enough.

When things aren't going smoothly, eg a broken leg, sometimes I just have to run the show without a timer for the act.

If it could just start automatically that would be so much better.

[cpvalente]

Hi @abhibeckert , thank you for getting involved. great to get some feedback.

I would suggest that perhaps one of the integrations could be used to start the time? so that it could be triggered by lighting / sound.
Or otherwise, how would make the timer start? What do you think?

[sagerian]

Hey

Apologies back for the slow reply. I've been flat out at work but I have also implemented a proof of concept system across our current site which shows potential.

Do I understand correctly that actual start / end would be a record of when did the operator started the running event and actual end when the playback moved away from this event?

Yeah, basically the functionality I would love to see is the ability to look at the scheduled times versus their actual times. For us this would mean we can keep an eye on particular acts if they're starting to drag etc.

What is the duration of an event with just start? is it extrapolated from the next event start in which case it becomes just a shortcut to ease time entries?

The next event start, or it might be a stop or pause or some other input. In an ideal world this could be exported or saved as a text file

what happens to roll mode? if the event doesnt have an end, when do we consider it finished?

I appreciate roll mode adds an extra layer of complexity. It feels like a good litmus test. Does it need an end?

[sagerian]

On a slightly different note. Here's my the environment I made for our current show

This show is particularly QLab heavy so there was basically a good cue to drop the OSC command in to. Only issues I ran in to were my own making (devamps can use group mode start first child and go to next cue)

This allows bars and site management staff to keep an eye on where the show is up to.

[cpvalente]

Hi @sagerian and @abhibeckert
I know its been a while, but I would like to add this next to the roadmap.

The current specification is something like:

• Create a reporter service that watches the playback
• It should record events (play, pause, stop...) along with their times and the affected event in the rundown
• You can export this as a CSV file to use in Excel
• The report exists for an app session (lost on closing the app)

The data contained would look like

• Time of first play
• Time of stop

Along with a list of your events, and the report of their playback, eg: for a single event

• Event Name: Your event
• Event Scheduled Start: 19:20:00
• Event Started at: 19:20:30
• Event scheduled end: 19:30
• Event ended at: 19:34
• Event scheduled duration: 00:10:00
• Actual duration: 00:13:30

The data would relate to the last time something happened in an event. Meaning that if you were to run the same timer a few times, you would only see stats for the last run

Could you please share some thoughts?

@sagerian Some other things you mention:

An OSC command to move the cursor to a specific event and play immediately
You can do this with the startid or startindex commands
https://ontime.gitbook.io/v2/control-and-feedback/ontime-apis

Option to start some events manually and others automatically (show call is always 5:30 and could be auto, show start depends on a billion factors and would be triggered by QLab)
This is now possible with the endBehaviour automation. I will update this comment was it is documented

Option to have start time only. Oour showcall is 5:30 but it doesn't have a scheduled end. It's over when you leave the venue for the night. For comparison, our interval will have a specific end time as it is crucial we don't go over the 20 minutes. In this example, the end time would be decided by when the interval start is played.

We have a few requests along this lines and we have paved the way to make it happen in v2. However I am unconfident on the details. Perhaps you can help?

• If I understand your prompt correctly, the Show Call would be an encompassing event. That is something that is not possible in ontime

As for start only, could you take a look at a similar thread #59 (comment)

[cpvalente]

Most of the improvements here have been implemented over time.

The missing part, which we called event reporter, doesnt seem to have received enough community interest to be considered worth it by us working with Ontime

I am happy to reconsider a implementation as described above if this changes
#165 (comment)

Meanwhile I will close this issue