Question: non-linear graphic steps

[rinode]

So the step model is visualized as a linear path:

However, the documentation doesn't specifically mention whether a step is meant to be linear (i.e. a 'marker' on a timeline), or can be non-linear, such as the following example:

In this example, directionality of transitions affects the step it will traverse.

Another example:

Is OGraf's step model restricted to linear timelines, or can steps diverge to (and join from) separate paths?

[didikunz]

As I understand it, the step model is more in a linera fashion. What you show here can be represented with custom commands.
Call "step 1" then either "A", "B" or "C" and then "step 2". While the steps would maybe not be called "step X".

[rinode]

@didikunz

As I understand it, the step model is more in a linera fashion. What you show here can be represented with custom commands.

Just to be sure, you're referring to the customActions field right? Makes sense, thanks! Doesn't seem like you can limit custom actions to a certain step from an API point of view, right?

[dvdeurse]

The step model does not have to be linear. I don't think OGraf should have an opinion about what steps mean. It is the implementer of the Graphics that determines the semantics of the steps for that Graphics. All OGraf defines is

• the fact that a Graphic can have multiple steps
• a step is identified by a number
• a function to navigate to these steps (either absolute or relative).

What this actually means (i.e. rendering a particular step) is up to the Graphics implementer and can depend on internal state, external state, step number, etc. And yes, you could use custom actions to manipulate the current step, if that is necessary, but it shouldn't be a requirement to implement non-linear step models.

[christianeide]

I agree that the step model should not be locked to a linear, I have several usecases where a non-linear step model makes sense. F. ex. if you have several images in a full screen or studio screen, then we would like to jump to whatever image the user wants.

With that being said, from my own experience it is more demanding to create graphics that handles non-linear playout. So I dont think Ograf should demand that everyone should support non-linear step logic. And at the same time not limit users to only support a linear step logic.

Should this be a configuration the graphic instance declears? If the graphics can handle non-linear, or orderLocked, step?

[didikunz]

The OGraf specification actually supports a non linear way of the stepCount. That is correct. If that makes sense or not is not the point. Actually you can either use the stepCount or could use a customAction. That depends on the use case, while you only could give the stepCount (a number) as a parameter in the first case you can send a full payload with data (variables etc.) in the second case.

By the way: I would do the use-case of the studio screen you mentioned by updating the image and not by loading everything beforehand and step back and fore. But it sure could be done that way if it makes sense for any reason.

[rinode]

Going from a step to a directly connected step feels natural, but with diverging/joining paths and being able to select 'multiple steps ahead' complexity arises (multiple possible paths to the same step). Then again, why would you introduce diverging paths if you don't explicitly want to traverse them... I'm not big on introducing another mode, but if we want to fully support this it might be good to provide the necessary feedback to determine which steps can be taken.

[didikunz]

Hmmm. I think there is a slight misunderstanding here. The diagrams are meant to show possible ways to call these steps, not the way they must be called.

In CasparCG we have the "Next" command, that works similar, but in a less flexible way. It simply calles the next step, without giving the operator a way to skip steps. In my understanding the nextStep variable is more to be able to skip steps to preview a step before putting it on air, similar to the "skipAnimation" flag. Mostly this step animations are used to either show other pages of informations (like for a ranking in sports) or to reveal something, like having a bars showing the points/percentages in a voting and revealing the actual names of the winners one by one. In such scenarios it can be handy to be able to skip to a step to see it as preview but would ruin the tension if used on air.

So I would keep this stuff as simple as possible and not over engineer it too much. But that is only my opinion.

[rinode]

It feels like we've reached consensus about this: steps can be non-linear, but step transitions are unopinionated and left to the implementer to handle correctly.