Point cue numbering / display

[martin-144]

Today I found an oddity when recording point cues.

For example I record a cue 1.9 - everything is fine. Then I record a cue 1.10, which is displayed in the cue list as 1.1.

When I later try to record a cue 1.1, it warns me that cue 1.10 already exists. Strange.

It seems that cues with .10 .20 .30 and so on are treated as if the trailing zero doesnt exist. Any ideas?

Martin

[Edward Z88]

Hi Martin,

The console will always put your cues in to the greatest value it can. Therefore to record the very first available point cue you would have to type .01, rather than .1 - which although the second decimal place is missing is in fact .10, as that is the tenth point cue available. This tidies up the programming, so that every time you have a single point cue between 2 cues you just see .5, rather than .50.

Hope that makes sense,

Edward

[Jon Hole]

Don't see the numbers after the decimal place as starting to count again, see the whole number as a decimal - just like how a Calcualtor or Excel would see it.

1.1  =  1.10  =  1.100000000000000

[martin-144]

Hi,

interesting approach to that. As I am mainly doing theatre, I used to use the point cues to depict my scenes. And there could be some scenes with over ten cues.
So this would look a little bit weird to an operator who has to do the show. But I think we can come along with that.

So we could have the following cue stack:

...
1.08
1.09
1.1
1.11
1.12
...

which looks a little bit strange...

As I understood, the point cues are limited to 99, so why not always have two decimals after the delimiter?

Martin

[Jon Hole]

Hi Martin,

The way ZerOS displays Point Cues is relatively standard across the industry. Point Cues are primarily designed as a method of adding in “extra” cues, and so usually a single decimal place is ample.

Jon