diff options
author | Vito Caputo <vcaputo@pengaru.com> | 2023-01-19 23:01:07 -0800 |
---|---|---|
committer | Vito Caputo <vcaputo@pengaru.com> | 2023-01-21 13:34:12 -0800 |
commit | 348eaf96c8b38795319d785a0b1f1749ffb1a55a (patch) | |
tree | f3cbbfce78bffc69d14ec9987d85cdb5472d1e38 /configure.ac | |
parent | a583ead0f41e6bcec76b32a95985667fdbe2192a (diff) |
modules/rocket: implement GNU Rocket integration
This adds a rudimentary but functional rocket module for
sequencing "tapped" variables in rototiller modules according to
a timeline via GNU Rocket editors.
Currently this only supports a single seq_module= as a setting
which will be used for rendering. Any tapped variables present
in the nested modules under seq_module will be available for
sequencing, and should automatically appear in a connected rocket
editor.
If you specify connect=off then rocket sync tracks will be read
from the filesystem if present. It's a bit clumsy as-is due to
how the GNU Rocket library handles this currently. There's a
"base" label concept for the virtual rocket device, and the
tracks are intended to be files in a directory named using that
base= setting.
The way you create those track files is by triggering a remote
export from the editor while connected. The location of the
directory is relative to the cwd of the rototiller process, and
you can't specify absolute paths as the base= setting to be
explicit about where things go. The setting isn't really a path,
as that's not what the library wants it to be. It's an area in
need of improvement.
In any case, as long as you start with the same base= setting,
from the same CWD, as when you did the remote export, you can
re-run with connect=off and the exported tracks will be used
automagically and things should replay without the editor
connected.
If you start with connect=on, which is the default, you need to
have the editor already running. Otherwise the rocket module
will fail @ context create, and you'll get a confusing error
about being unable to allocate memory. This is just for now, the
context create needs to start returning an errno instead of just
the context pointer so the error messages can be more informative
now that context create may be doing complicated things like
connecting to sockets.
Another thing to improve is probably having the module just
reconnect periodically if connect=on but it failed @ context
create. It could just start anyways and not fail the context
create at all there, and just start working once you get the
editor online. That'd be a better user experience.
This is a good first step regardless...
Diffstat (limited to 'configure.ac')
0 files changed, 0 insertions, 0 deletions