Ready, Steady ... (pause) ... Go

[martinglass]

At present the staging can be set by "Minimum Start Delay" and "Maximum Start Delay", which provide the existing staging beeps (and synchronised LED lights).

But they do not reflect what is commonly expected for the start of a race.

Races using "standard" systems provide a Ready-Steady (staging short beeps)...(random length pause)...Go (long beep) sequence. It might be thought of as a two-phase staging process, instead of the present one-phase staging process.

For example, could existing the two options could change from [(min start delay) and (max start delay)], to say [(fixed staging time) and (max random time to race start)], which would not even make the UI more complicated.

Using this approach, the Race Management would initiate a race-start (from the manual or scheduled selection), with beeps that sound for the number of seconds as set by ("fixed staging time"), using tones defined by "Staging Tones", namely either [none, one a second, or ending in a 1-2-3 staging], then followed by a random length pause, set by ("max random time to race start")

[pulquero]

Can we include a statement of the existing sequence so the difference is clear?

[martinglass]

Yes, but it would require something like a tick box in the UI or a line in config.json to choose between legacy mode or not.

[HazardCreative]

It's not all that different from how it works now and I do not think a "legacy mode" is needed. It sounds different on its face, but the requested effect could be produced with the current (min) (max) parameters. (fixed) (random) provides a different mental model but not truly different information. (Min) and (fixed) are identical. The (random) part is just (max) - (min). As I'm thinking about naming the tone settings, keeping (min) could make more cognitive sense.

However, the above is only true if the minimum of the (random) part is always zero. A tone sounds at the beginning of the second, so (fixed=3) (random = 0) is equivalent to Beep .. Beep .. Beep .. Go. If you changed to (random=1) then Beep .. Beep .. Beep .. Go is still a possible outcome, as is Beep .. Beep .. Beep .. (wait) .. Go. What would not be possible with this is to always have one or more no-tone seconds before the near edge of the random phase (Beep .. Beep .. Beep .. (wait always) .. (wait maybe) .. Go). To have this minimum delay within the (random) part complicates the process further. It is also immaterial with any other tone settings. Is it necessary?

The important parts of the request are tone settings and a signaling trigger that correspond with the end of (min).

Staging and race start are synchronized events that require blocking processing on the server. This request will require a new "mid-stage" event that is also blocking. Simply adding that event will be enough to satisfy accessibility concerns as the LED system can react to that event (or not) as desired by the RD. Suggestions on default LED effects for mid-stage are welcome. I'm thinking the default might just be to turn the panel off.

Staging tone settings could become:

• None (exists)
• Staging begins (this is just a clearer naming of the existing "one" setting)
• Staging begins and minimum ends*
• Each second under minimum
• Each second (exists)

Mid-stage should be understood as an "optional" event that does not fire if the random value was 0, either by force or by chance. One thing that gives me pause here is the "minimum ends" (asterisked above) tone setting. There would be periods where mid-stage did not exist and that tone would not sound. Perhaps that setting is actually processed more like "staging begins, and last second before minimum ends if max>0"? Or maybe we just make it "Staging begins and last minimum second"? But this approach breaks accessibility, because the mid-stage event and the signaling wouldn't be in sync. Feedback welcome here.

[martinglass]

Here's what the FIA states for Formula 1 racing..."[following a series of 5 1-second countdowns] After a preset delay of between 0.2 and 3.0 seconds, the race is started." That's the sort of thing that's needed.

I guess Race Directors can choose as many 1-second countdowns as they want, from 0 upwards, but there needs to be a random delay after the countdown to start the race,

It is important that this delay is measured in 1/10ths of a second or less, and not rounded to the nearest 1-second.

[HazardCreative]

We'll have to move to a system that requires 3 variables instead of two: fixed, random min, random max. It's possible to create the above specific scenario with just two, but it requires some cognitive work that I don't want to put onto RDs (min=4.2, random=2.8).

We have to consider some cognitive dissonance here around number of tones. (fixed=5 min=max=0) only has 5 tones if we begin each second with the tone because 0 is the start tone. With that strategy (fixed=5 min/max>0) means 6 tones because there now must be one at the 0 mark. Do we shift to end-of-second tones if min/max > 0, so that fixed=5 always means "5 tones"? (This is effectively implemented as fixed = fixed - 1, for practical—and accessibility—purposes.)

[martinglass]

It is important that this delay is measured in 1/10ths of a second or less, and not rounded to the nearest 1-second.

Just to clarify this: The user/RD just chooses a max number of exact seconds for the delay, then the server calculates the random choice (a surprise!) measured in 1/10th seconds or less (ranging between 0.2 sec and the max. number of seconds specified by the user/RD)

[HazardCreative]

I don't think the 0.2 minimum is a constant across race groups.