summaryrefslogtreecommitdiff
path: root/src/modules/rkt
AgeCommit message (Collapse)Author
2023-07-05modules/rkt: rkt_scener_send_message() in another spotVito Caputo
Trivial related indentation adjustment too
2023-07-05modules/rkt: introduce a rudimentary scenes editorVito Caputo
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.
2023-07-05modules/rkt: resolve module_name->til_module_t in setupVito Caputo
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.
2023-07-04modules/*: return invalid setting on -EINVAL in setupVito Caputo
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.
2023-07-04modules/rkt: discretize rkt_context_t.scenes[]Vito Caputo
Make this a distinct heap allocation so it can be enlarged when editing the scenes... (preparatory commit for scenes editing)
2023-06-24modules/rkt: move rkt types to a headerVito Caputo
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[].
2023-06-15modules/rkt: drop vestigial TODO comment about handlesVito Caputo
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.
2023-06-15modules/rkt: end the stream on scene 99999Vito Caputo
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...
2023-06-15modules/rkt: handle stream taps @ context createVito Caputo
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.
2023-06-13*: smattering of random small fixes to silence -WallVito Caputo
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.
2023-06-08modules/rkt: drop vestigial module_setupVito Caputo
a390e82 stopped using this, but didn't remove it. As it was initialized to NULL, it was deffectively all a NOOP.
2023-06-08modules/rkt: detect errors when creating scene contextsVito Caputo
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.
2023-06-01modules/rkt: deprecate seq_module= in favor of scenes=Vito Caputo
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.
2023-06-01modules/rkt: use local variable for rkt_setup_t*Vito Caputo
Mechanical change removing some rkt_setup_t* casting verbosity in rkt_create_context()
2023-06-01modules/rkt: use helper for pipe track namesVito Caputo
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().
2023-06-01modules/rkt: variadic warpper for sync_get_track()Vito Caputo
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)
2023-05-30til: s/til_module_randomize_setup/til_module_setup_randomize/Vito Caputo
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
2023-05-30til,*: pivot to til_setup_t for context pathsVito Caputo
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.
2023-05-28til_setup,*: note settings path in til_setup_tVito Caputo
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.
2023-05-28*: use NULL for free() in til_setup_new()Vito Caputo
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.
2023-05-11til_module_context: reference setup from module contextVito Caputo
This just does the obvious pulling in of til_setup_t, holding the reference throughout the lifetime of the module context.
2023-05-11modules/*: remove use of static default setupsVito Caputo
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.
2023-05-11til_settings: introduce til_setting_spec_t concept vs. descVito Caputo
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.
2023-03-13modules/rocket: mv modules/rocket modules/rktVito Caputo
Finishes build/fs part of modules/rocket->modules/rkt rename started in previous commit.
© All Rights Reserved