modules/rkt: deprecate seq_module= in favor of scenes=

This drops the seq_module= setting in favor of a scenes= setting
in the same style of compose::layers; a nested settings instance
composed of more nested settings instances, one per scene.

A nice side-effect of this change is it no longer uses
til_module_setup_randomize() at all, which was being used to mix
up the seq_module's settings in a pre-nested-settings world.

A new Rocket sync track is introduced named "$context_path:scene"
for selecting which scene to render.

For now all scenes get created @ context create time, and persist
for the entire rkt context lifetime.  In the future the context
lifetimes might become explicitly controllable with separate
Rocket tracks used as booleans.  This becomes relevant once
modules can make use of existing contexts located within the
stream at their respective context paths.  Something necessary
for integrated transitions between scenes using stuff like
fade modules which haven't been added yet.

With this change you can already enumerate a set of scenes in the
rkt settings string, each 100% explicitly configured, and have
Rocket track data select which scene to render on the timeline,
and manipulate the taps at their scene-specific
context-path-derived track names.

In addition to the need for modules picking up existing contexts
on the stream, rkt probably needs a way to interactively
add/remove/modify scenes then spit out the serialized settings
string for the current state of the world.

As these aren't functionalities provided by GNU Rocket, and it's
unclear how receptive upstream GNU Rocket/glrocket maintainers
would be to such additions, rkt will likely first add another
listener for a strictly scenes-editing client to connect
alongside the GNU Rocket stuff.  Just something that shows the
current scenes table, and provides a way to edit/add/remove rows
there, with the changes realized in rkt real-time.  Then the
Rocket Editor will just continue using the rkt:scene track to
numerically index into this scenes table, without the Rocket
Editor having any visibility or awareness of what's going on in
that table.  Probably ok as an initial stab at making demos with
this stack.

0 files changed, 0 insertions, 0 deletions