| Age | Commit message (Collapse) | Author |
|---|
|
This augments the NEWSCENE_SETUP state to also handle editing
existing settings, which is slightly different but actually
overlaps with the already implemented invalid input stuff.
There's still work to do, and the UX is kind of awkward at best.
But this takes us from having no ability to edit existing scenes,
to being able to actually make edits interactively while it's all
live... with a modicum of interactive guidance via the setup
machinery.
It basically behaves just like creating a new scene, except
instead of the <enter>-accepted "preferred" values, you accept
the existing relevant setting. So as-is, when editing, you have
no shortcut for getting back the "preferred" value for a given
setting. That's been replaced with the existing value for that
setting.
You also get seemingly spurious redundant queries for module
names in things like compose::layers, but they're really not the
same since the first time you get asked it's actually the full
settings string you're getting an opportunity to specify
wholesale, but can accept to seed the layer's settings as-is,
which you will then be given an opportunity to edit piecemeal.
It's that subsequent piecemeal editing of the individual settings
within the nested instance that can feel like a spurious
duplication, especialy when a given layer has just a bare-value
module name and no subsequent settings.. like "plasma". You'd be
asked if you want "plasma" for the layers/[N], then asked if you
want "plasma" _again_ for the layers/[N]/[0] since the module
name is an unnamed setting at position 0 within the layers/[N]
instance.
It was tempting to try streamline that a bit, but there's
actually utility in having an opportunity to paste in a full
settings string for the layers/[N] if you have a serialized scene
onhand you want to dump in there. Then after that, you can juts
smash enter as much as necessary to accept what you pasted in
without editing those in the piecemeal phase. Or, if there was
actually something in what you pasted you did want to change,
change it during that piecemeal phase.
I think it at least kind of works.
|
|
Better spearate the generic error line from surrounding text with
an extra newline
|
|
This was a bit of an aspirational misnomer, editing scenes isn't
actually implemented yet. What the EDITSCENE state currently
implements is the per-scene dialog+prompt, which originally was
going to just be the scene editing flow but became more of a
"view a specified scene's details" with a prompt of its own.
Nothing functionally changes, just mechanical internal renames.
|
|
This is leftover from development when it used a fmt string in
combination with the key, before the desc path was getting
properly appended.
|
|
On Linux I don't notice a significant affect on anything letting
rkt try connect every frame when offline but in creative mode.
On Windows however, Dan reported significant latencies in the
Scener prompt responsiveness and visible slowdowns in this
condition.
I suspect the WIN32 Rocket library's sync_tcp_connect() code is
the real problem here. But for now I can ameliorate things a bit
by just hammering on that code path less when unconnected.
|
|
This is only relevant to creative mode. Stops RocketEditor from
continuing playback endlessly until user intervention beyond the
current end of the demo.
|
|
Prepartory commit for pausing playback upon entering 99999 scene
It needs to trigger only on the edge of entering the scene to
permit RocketEditor to unpause playback even if still in scene
99999, if that's what the user is trying to do. It'd be annoying
to have it just keep asserting a paused state until the scene idx
leaves 99999...
But this also enables triggering anything on scene change edges,
for future stuff.
|
|
- strip off the leading /path/to/rkt/module prefix
- separate taps from their scene context path with ':' vs. '/'
RocketEditor doesn't currently support recursive grouping, so
this is as good as it gets.
Note this commit will break the existing tracks for alphazed, so
you'll have to use a newer .zip for track data if building your
rototiller from source. Or build from a prior commit.
|
|
Preparatory commit for rewriting track paths a bit to better
group things in RocketEditor. I'll need access to
rkt_context_t.til_module_context_t.setup->path for prefix
matching purposes..
|
|
During rkt_scener development this append was at one time needed,
as there was no retained reference to the scenes_settings for
deriving paths from.
Now that the path is derived from the actual scenes setting
instance it's just resulting in a double trailing /scenes in the
"/module/rkt/scenes/scenes:" heading
Purely cosmetic fix
|
|
Pressing '=' at either prompts now makes scener's current scene
the current Rocket scene.
While you could already do this manually by just looking at the
scenes list for the one with the '*' in the Rocket column while
either watching a production and pressing <enter> repeatedly to
keep refreshing the scenes list... that's cumbersome and
annoying, now just use this shortcut.
Since this just copies Rocket's scene to the Scener scene index,
it needed to properly handle scene 99999... hence the previous
commits.
|
|
While there's no actual context for 99999, it's a state we need
to represent visibly somehow.. so just make it appear like an
epilogue scene off the end.
I've included the Rocket/Scener/Pinned status columns
consistently as well so you at least still get a visible
indication when you've done something like pinned 99999 somehow
(not that this is possible presently, but with future changes
there will be more ways to copy the Rocket idx into Scener's idx)
|
|
rkt_scener needs to know this value so define it in rkt.h and
switch over all the existing 99999 instances.
|
|
This seems to make things work well enough for mingw+wine
Will probably revisit in the future. Adding an ewouldblock
helper rather than duplicating the ifdeffery seems likely
Let's just leave it like this for now and find out if a real
windows test succeeds
|
|
This is available in win32, unlike inet_aton()
|
|
|
|
trivial simplification
|
|
Silly typo, one of those fun C instances where it's surprising
how silently mostly-working such a blatant mistake can be.
For posterity:
The way this was even observed as having an affect is while
verifying graceful handling of connections broken while in the
listen backlog.
With an active scener session idle at the prompt, start another
telnet, connecting without receiving any banner (queued via
backlog), ^]cl that backlogged telnet. Then start another
telnet in the same way. Now go to the idle scener session and
quit. The latest telnet would just sit there, seemingly blocked
behind the broken-while-backlogged connection.
But what was really happening was the banner send got the error
on the broken connection after accepting, as you'd expect. This
bug in the errno tests prevented detecting the genuine error
though, leaving the broken session connected indefinitely.
Fun!
|
|
After putting the recv() in a for(;;) to not have to render a
frame per byte received, I completely dropped the ball on moving
the return and adding the continue to actually finish the change.
This makes creating new scenes via pasting long settings strings
far less laggy. A future improvement would be to not recv() a
byte at a time, but this really isn't a perf-sensitive thing.
|
|
This changes things so rkt won't exit with an error @ startup if
RocketEditor isn't already listening. It also tolerates
RocketEditor going away, and will show a "OFFLINE" overlay status
text should that happen w/connect=on.
Some status text has also been added to the "EXIT SCENE" 99999
scene for both the RocketEditor connection and the scener
enabled/disabled status. No indicator yet for if scener has a
connection though, only if it's listening or not via listen=on.
|
|
Remove spurious space
|
|
|
|
Trivial related indentation adjustment too
|
|
This adds a BBS-style interface for creating new scenes in a live
rkt session.
It listens on tcp port 54321 on localhost by default, just use
telnet to connect, the rest is fairly self-explanatory.
This is still early days, but it's a whole lot more than nothing.
|
|
With the "ref" builtin module established and seeming to work
well enough, it looks unlikely we'll need access to unresolvable
module names in the contexts.
The thinking originally was that these names might have special
syntax making them more generic. E.g something like
"@/module/rkt/scenes/[1]/drizzle" for a module_name would have
been supported, which would get resolved either at context create
or even later (as in the ref builtin) at render time.
But the ref builtin is using a path setting, so module names just
stay module names.
Maybe in the future a special syntax will be added for brevity
reasons, but it does make the code more complicated vs. module
names just being names and resolving them entirely at setup time.
Anyhow, this commit does away with the module_name in the
context's scenes. You can still access it via
til_module_context_t.module.name anyways... it's basically just a
resolution-of-name-to-context time constraint that's being
codified now.
|
|
In the interests of improving error handling of interactive
setups, return the setting that was invalid when setup returns
-EINVAL.
For now this is only supported for non-finalized/non-baking setup
calls, i.e. (!res_setup).
In the future I want this also supported for finalizing when
res_setup is set. A lot of the -EINVAL returns are actually
during that stage (or need to be added) due to that being when
the more sensitive parsing occurs going from strings to native
numeric types and such.
The main reason it's not already being done in this commit is
it'll churn quite a bit to get there, since the setup funcs don't
generally have the setting pointers onhand at that phase. It'll
require changing the string-value-centric local variables to
instead all be the til_setting_t* holding those values.
And if setup funcs aren't going to be so value-centric, the
settings API will likely change to not even return the values
directly anymore and only return the full-blown til_settings_t as
the main return pointer, perhaps rid of their res_setting use
even.
Anyway, while here I did some random little cleanups too.
|
|
Make this a distinct heap allocation so it can be enlarged when
editing the scenes... (preparatory commit for scenes editing)
|
|
Preparatory commit for adding an interactive scene editing server
of sorts. It'll go in a separate listing, but needs these types
as it'll operate on rkt_context_t->scenes[].
|
|
This was written when module names were going to have an
@/path/to/context "handle" syntax. But instead I went the "ref"
builtin module route, with path=/path/to/context as a setting.
While it's more verbose in the settings, it "just works"
everywhere that can take a module+settings because the ref
builtin is just another module like any other.
So this TODO is referring to something that won't happen in a
"ref" builtin world.
|
|
This conditionally will end the stream on scene 99999 if
connect=off (playback mode)
When connect=on it'll just make it show an "EXIT SCENE"
diagnostic instead of the "NO SCENE" message.
Now you just stick 99999 in the rkt:scene track to end the show.
It's assumed 99999 scenes will never be needed...
|
|
It's problematic getting this stuff online at render time,
because the modules end up rendering with uninitialized tap
values in that first frame.
With this change modules can get their taps on-stream at context
create, and we'll notice and do the initial rocket update just
before returning the rkt context to prime everyone on-stream.
|
|
I thought the build was already using -Wall but that seems to not
be the case, maybe got lost somewhere along the line or messed up
in configure.ac
After forcing a build with -Wall -Werror, these showed up.
Fixed up in the obvious way, nothing too scary.
|
|
a390e82 stopped using this, but didn't remove it.
As it was initialized to NULL, it was deffectively all a NOOP.
|
|
The return value was just being ignored previously, and that
really starts mattering in a world with contexts finding others
by user-supplied paths making such failures far more likely.
|
|
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.
|
|
Mechanical change removing some rkt_setup_t* casting verbosity in
rkt_create_context()
|
|
This eliminates the ad-hoc track_name[] allocation and
construction, since the track_name wasn't being used after
getting the track anyways. No point wasting the memory on it,
and the little helper constructing the name on-stack exists now
for another future use @ rkt_create_context().
|
|
Preparatory commit for adding scenes and a $rkt_setup_path:scene
track for selecting them. This will also likely replace the
whole track_name allocation/construction in rkt_pipe_t since we
don't actually make use of that name after getting the track
(except maybe for debugging purposes)
|
|
Mechanical rename just to make this consistent with
til_module_setup()/til_module_setup_finalize()
I should probably do a cleanup pass throughout the til APIs to
standardize on a subject-verb-object or subject-object-verb
order... Things have become a little inconsistent organically
over time
|
|
This changes til_setup_t* from optional to required for
til_module_context_t creation, while dropping the separate path
parameter construction and passing throughout.
|
|
This commit adds passing the settings instance to til_setup_new()
which is used for deriving a path for the setup via
til_settings_print_path() on the supplied settings.
That path gets an allocated copy left in the returned
til_setup_t at til_setup_t.path
This path will exist for the lifetime of the til_setup_t, to be
freed along with the rest of the baked setup instance when the
refcount reaches 0.
The incoming til_settings_t is only read @ til_setup_new() in
constructing the path, no reference is kept. Basically the
til_settings_t* is just passed in for convenience reasons, since
constructing the path needs memory and may fail, this approach
lets the existing til_setup_new() call error handling also
capture the path allocation failures as-is turning
til_setup_new() into a bit more of a convenience helper.
Note that now all code may assume a til_setup_t has a set and
valid til_setup_t.path, which should be useful for context
creates when a setup is available.
|
|
Commit 7c8086020 switched the til_setup_new() api to support NULL
free_func for free().
This mechanical change pivots to that instead of the awkwardly
cast free() parameters.
|
|
This just does the obvious pulling in of til_setup_t, holding the
reference throughout the lifetime of the module context.
|
|
There was a time when it made sense for context creates needing
setups but not receiving them to still be functional with some
sane defaults.
But with recursive settings, we really shouldn't ever have
orphaned nested module uses unreachable by a proper setup.
So let's just get rid of this fallback, and exclusively rely on
the baked setups provided by the .setup() methods. They still
have preferred defaults, and the proper setup production
machinery is what should be responsible for applying those
at runtime where they may also be overridden or otherwise
influenced.
|
|
For recursive settings the individual setting being described
needs to get added to a potentially different settings instance
than the one being operated on at the top of the current
setup_func phase.
The settings instance being passed around for a setup_func to
operate on is constified, mainly to try ensure modules don't
start directly mucking with the settings. They're supposed to
just describe what they want next and iterate back and forth,
with the front-end creating the settings from the returned descs
however is appropriate, eventually building up the settings to
completion.
But since it's the setup_func that decides which settings
instance is appropriate for containing the setting.. at some
point it must associate a settings instance with the desc it's
producing, one that is going to be necessarily written to.
So here I'm just turning the existing til_setting_desc_t to a
"spec", unchanged. And introducing a new til_setting_desc_t
embedding the spec, accompanied by a non-const til_settings_t*
"container".
Now what setup_funcs use to express settings are a spec,
otherwise identically to before. Instead of cloning a desc to
allocate it for returning to the front-end, the desc is created
from a spec with the target settings instance passed in.
This turns the desc step where we take a constified settings
instance and cast it into a non-const a more formal act of going
from spec->desc, binding the spec to a specific settings
instance. It will also serve to isolate that hacky cast to a
til_settings function, and all the accessors of
til_setting_desc_t needing to operate on the containing settings
instance can just do so.
As of this commit, the container pointer is just sitting in the
desc_t but isn't being made use of or even assigned yet. This is
just to minimize the amount of churn happening in this otherwise
mostly mechanical and sprawling commit.
There's also been some small changes surrounding the desc
generators and plumbing of the settings instance where there
previously wasn't any. It's unclear to me if desc generators
will stay desc generators or turn into spec generators. For now
those are mostly just used by the drm_fb stuff anyways, modules
haven't made use of them, so they can stay a little crufty
harmlessly for now.
|
|
Finishes build/fs part of modules/rocket->modules/rkt rename
started in previous commit.
|
