summaryrefslogtreecommitdiff
path: root/src/modules/rkt
AgeCommit message (Collapse)Author
2023-11-17modules/rkt: pause audio too on no scene/end pauseVito Caputo
There's already a pause triggered here, but the audio wasn't getting paused as well.
2023-11-14til_stream,rkt,main: add stream audio controlVito Caputo
Until now everything interested in audio just used a plain getter on the stream to get at the context. But with how things work currently, audio is always left in a paused state until explicitly unpaused. This works fine with modules/rkt, which manages pause/unpause explicitly. When there's nothing like modules/rkt in charge though, the audio just sits stuck paused. Meaning if you do some simple thing like --module=playit, it won't ever get unpaused. With this commit, something like modules/rkt takes control of the stream's audio context, in a way that prevents anything else from taking control of the same context on the same stream. That enables having main try take control of the audio context after creating the module contexts, then in the rendering thread ensure the audio is unpaused if main is in control of the audio context and something's queueing audio frames. For now there's no mechanism for releasing control of the audio context. It doesn't seem appropriate to make this more elaborate than necessary. There's basically just two use cases WRT audio: 1. Something like rkt, which takes control once for the process and stays in control until process exit. 2. Something far simpler where nothing's taking control like rkt, and main just needs to get things unpaused when needed because something's generating audio frames.
2023-11-14modules/rkt: begin til_audio integrationsVito Caputo
- til_audio_seek() when Rocket sets the row - til_audio_{pause,unpause}() when Rocket (un)pauses This is of limited use as-is, rkt probably needs a sister concept of scenes for songs, which similarly to scenes would be selected by index in a discrete Rocket track. As-is to make music work one must always incorporate something like a modules/playit context into the current scene so it always gets rendered alongside the visuals. That's quite cumbersome and annoying. Another possibility would be introducing something like a "register" built-in that, like "ref", takes a context path, and maybe something like a pre/post setting. That would put it in the rendering path of the stream before or after any explicit renders... Then all one would need is to register a modules/playit context with the song of interest to have it play, and create that as any other rkt "scene", and reference its context from "register" which could bind a tap for controlling the registered/unregistered state. It needs more fleshing out, but what's here seems worth merging as-is for now.
2023-11-03modules/*: drop til_setup_t.free_func() NULL setup checksVito Caputo
Trivial cleanup. These are unnecessary nowadays since til_setup_free() won't invoke the free_func() on a NULL setup, and everything uses til_setup_free() to free a til_setup_t.
2023-10-03libs/txt,modules/*: rename txt_render_fragment()Vito Caputo
Mechanical rename to txt_render_fragment_aligned(), updating all existing call sites accordingly. This is a preparatory commit for introducing an offsetted variant of txt_render_fragment() (txt_render_fragment_offsetted()). No functional difference, purely naming changes.
2023-08-31modules/*: use til_setup_free_with_ret_err() where aproposVito Caputo
Just some more res_setup baking failure path cleanups, largely mechanical change.
2023-08-31modules/rkt: better handle EINVAL errors on finalizeVito Caputo
Similar to setup_interactively(), rkt_scener needs to handle EINVAL errors on res_setup baking @ finalize. Until now it had handled EINVAL @ finalize by failing the operation and returning to the main scenes prompt. With this commit rkt_scener now returns the user to the failed setting, enabling correcting the problem. It's a little janky, but not too bad. See comments for why.
2023-08-30modules/rkt: handle baking errors in rkt_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-29til: s/til_module_setup_randomize/til_module_settings_randomize/Vito Caputo
Mechanical rename for clarity reasons, primarily to better differentiate from the setup_func style til_module_setup()/til_module_setup_full() functions.
2023-08-29modules/rkt: drop ad-hoc last_ticks trackingVito Caputo
Commit 64a5b17 added this to til_module_context_t, so it's already being tracked now making this redundant.
2023-08-19til_stream: set frame in til_stream_pipe_set_driving_tap()Vito Caputo
This needs the stream pulled in so the signature changed to accomodate that. Also modules/rkt was calling this conditionally which won't be compatible with the per-frame driver race model, so always call it to maintain the driving position every frame.
2023-08-14modules/rkt: stop leaking rkt_setup_t.scener_addressVito Caputo
Another trivial leak fixup.
2023-08-14modules/rkt: gc module contexts after scener editsVito Caputo
This triggers immediate cleanup of the replaced context. It's being done after the new context is fully installed as the replacement, with an eye towards enabling a baton style handoff of the existing context's owned pipes to the replacement, for taps they have in common. That's not being done yet, but it'd be impossible if the gc occurred before creating the replacement, since the existing context's pipes would already be untapped (and removed).
2023-08-14modules/rkt: free rkt_context_t.scenes in rkt_destroy_context()Vito Caputo
Another trivial leak fixup
2023-08-14modules/rkt: wire up pipe_dtor to stop leaking rkt_pipe_tVito Caputo
On shutdown til_stream_untap_owner() will call into the pipe_dtor hook if set. So until now this was just (harmlessly) leaking the rkt_pipe_t allocated by the pipe_ctor hook on the road to process exit. But in the interests of silencing ASAN about leaks on graceful exit, I'm tying up these loose ends. This dtor will also be utilized for performing a FORGET_TRACK via Rocket once that's a thing. While here I also got rid of the pipe_dtor return value, as it's unused with no clear potential purpose (for now).
2023-08-07modules/rkt: add EDITSCENE state akin to NEWSCENEVito Caputo
Now you can seed the scene editing with a top-level serialized scene in "as_arg" form, just like NEWSCENE. The current scene being edited is shown in serialized form for convenient copy & paste into an editor for manipulation, between the []s both to also show what the default seed will be if you just press enter. When using the copy & paste w/editor approach, you'd just paste the tweaked form directly into the waiting prompt before hitting <enter>. Regardless of what happens at the initial EDITSCENE prompt, the current implementation always goes through an interactive visiting of all the settings. Simply pressing enter at those individual settings will accept their current value from the serialized seed, or a default if not present in the settings.
2023-08-07modules/rkt: make NEWSCENE state a simple functionVito Caputo
This doesn't need to be a distinct state since it's basically just a banner for the start of the newscene process which never recurs, it's not an interactive prompt or dialog of any kind...
2023-08-05modules/{compose,montage,rtv}: exclude builtinsVito Caputo
Basically everywhere the TIL_MODULE_HERMETIC|TIL_MODULE_EXPERIMENTAL exclusions were being applied needed TIL_MODULE_BUILTIN added. Mostly this is to prevent randomizers from tripping over builtins in the available modules lists they draw from. Because builtins aren't visually interesting by themselves, and in some cases don't currently even have a means of being randomized properly like ref's path setting. This wasn't needed previously since builtins were kept off the modules list altogether. But since 1a6210be that changed and they must be explicitly filtered by flag instead. Note I deliberately left the rkt case with just a TODO comment. It's not a randomizer situation, and it might be acceptable to let rkt just show everything all the time in the module lists. That whole situation there is for advanced users. Also note that without this, rtv et al would easily trigger an assert on NULL setup due to the "none" builtin. Since there's still work to be done there in callers properly handling NULL @res_setup on a successful finalize. But this commit mitigates that by avoiding the builtins in the randomizers.
2023-08-05modules/rkt: simplify setup finalizing via setup->creatorVito Caputo
This gets rid of the ad-hoc module lookups previously necessary for finalizing the nested module setups. Now that the til_estup_t.creator tracks the creating module, the rkt_scene_module_setup() wrapper can take care of finalizing.
2023-08-05til_setup,*: add til_setup_t.creator pointerVito Caputo
Particularly with nested modules it's annoying to have to stow the module separate from the setup during the setup process. If the baked setup included the module pointer in the non-module-specific-setup part of the setup, then nested settings could finalize using the generic module setup wrapper and just rely on this til_setup_t.creator pointer to contain the appropriate module. Which should enable tossing out a bunch of copy-n-pasta surrounding nested modules setup. Note this has to be a void* since til_setup_t is a generic thing used equally by both the fb code and the module code. Hence why this is called "creator" and not "module", as well as the void* as opposed to til_module_t*. Also if rototiller ever grows a sound backend, the setup machinery will be reused there as well, and it'll be yet another creator handle that isn't an til_fb_ops_t or a til_module_t. It's assumed that the callers producing these setups won't be trying to pass them to the wrong places i.e. a module setup getting passed to an fb backend and vice versa. I'm mildly annoyed about having to move the various til_module_t blocks to above the module's foo_setup(), but it seemed like the least annoying option. This may be revisited.
2023-08-04modules/rkt: make default module "compose"Vito Caputo
Most of the time in scener you want to add a compose, you basically never want blank, so the :blank thing was kind of silly from the perspective of what happens most often.
2023-08-04modules/rkt: utilize til_module_setup_full()Vito Caputo
rkt_setup() and rkt_scener_update() had distinct implementations for scene module setup. This consolidates that where trivial to both use the new til_module_setup_full() with appropriate parameters, wrapped up in rkt_scene_module_setup(). The finalizing phase is still ad-hoc which is mildly annoying, but if finalizing just passed into rkt_scene_module_setup() there wouldn't be the til_module_t onhand for sticking in rkt_scene_t. So the code to extract and lookup the module from the settings would still be needed anyways, as the whole til setup_func api isn't limited to modules so the baked til_setup_t doesn't come back with a til_module_t hanging in there. Maybe in the future this gets changed a bit, there could for instance be a void* in til_setup_t where something usage-specific goes, like the relevant module in the case of a module's setup. Something to consider for the future. Consolidating these in the pre-finalize phase at least ensures consistent behavior in initial rkt::scenes setup vs. scener editing/new scenes.
2023-08-03*: nested settings should get the raw valueVito Caputo
When creating nested setting instances, just pass down the full raw value so if there's any prefix on the value it can be realized as a prefix for the first entry in the nested instance.
2023-08-03modules/rkt,til: use set_raw_value() api for overridesVito Caputo
The application of overrides was still done via ad-hoc value manipulation. This changes to use til_setting_set_raw_value() in the obvious manner.
2023-08-03til_settings: honor til_setting_t.nocheck in spec_checkVito Caputo
Trivial refactor s/til_setting_spec_check/til_setting_check_spec/ so it operates on a til_setting_t as opposed to the bare value. With the containing til_setting_t onhand it can be responsible for bypassing the check when til_setting_t.nocheck is set. Adjusted callers in setup_interactively() and rkt_scener_update() accordingly.
2023-08-03modules/rkt: don't disconnect on -EINVAL from finalizeVito Caputo
It's relatively acceptable to use this hammer for the other errors like ENOMEM especially when this isn't some enterprise-y service that must endure overload conditions gracefully. But the setup_finalize() step is rather likely to find invalid settings, especially now that til_setting_t.nocheck with the ':' prefix is a thing. This commit doesn't try resume the setup at the invalid setting (yet, that will require further til_module_t.setup() method work), but it at least doesn't rudely disconnect. The user just gets dumped back to the SCENES state main prompt.
2023-08-03modules/rkt: use the raw module name when randomizingVito Caputo
The existing code assumed til_module_t.name was equivalent to the name setting's value. That's no longer a safe assumption, and if the module was made possible via something like nocheck, that needs to be preserved in the randomized setup. So this gets the name out of the setting instead, using the new raw value getter.
2023-08-03modules/rkt: support ':' prefixed setting valuesVito Caputo
This makes RKT_SCENER_FSM_SEND_NEWSCENE_SETUP* handle ':' prefixed values correctly, now using the new til_setting_[sg]et_raw_value() API instead of directly messing with til_setting_t.value. It should now be possible to specify anything as a value regardless of what's in the list for multiple choice settings. Which does create opportunity for serious breakages... there will definitely be crashes if you do silly things. Some til_module_t.setup() methods have historically assumed the spec_check would police the values reaching them. Those will have to be made more robust now that this is getting wired up.
2023-08-03modules/rkt: rkt_setup() s/blank/:blank/Vito Caputo
Since blank is a builtin, at least for now it requires explicit override since the builtins aren't added to the modules values list and filtering is going to be always applied shortly.
2023-08-01modules/rkt: make the default base= "rkt"Vito Caputo
The "tiller" base (base being a Rocket concept) was always a bit spurious. Maybe "til" would make more sense, but "rkt" is more contextually specific. I think when I originally picked "tiller" I was prioritizing picking something unlikely to collide with another directory name. But the way Rocket is naming the directory in the filesystem it gets suffixed with an _ anyways.
2023-08-01modules/rkt: make "blank" default scenes=Vito Caputo
The "compose,compose,compose,compose" default was never intended to be permanent, but gave a set of scenes to test the Rocket integrations like scene selection and scene-specific tracks without any additional effort. Now that there's scener for easily adding/editing scenes, and things are just generally more mature, I think it makes sense to just go back to something minimal here. I'd really rather just have it be "", but that's not handled well presently. There isn't really a way to start with an empty scenes set for rkt. Which is awkward, but "blank" is close. It'd just be nice to start with an altogether blank slate rather than having to always edit the default first scene when starting anew...
2023-07-31modules/rkt: remove TIL_MODULE_EXPERIMENTAL flagVito Caputo
Now that the "scener" interface seems to be semi usable and capable of editing... things are looking more complete in the sense that there's no huge gaping holes and a lot of the dust has settled. It's also looking pretty good for this sticking around long-term, so I'm removing the experimental flag making this more discoverable and visible in general. There's still work to be done surrounding GNU Rocket the library, like getting it using non-blocking connects, and there's a need for forgetting tracks which the protocol doesn't support currently. But it'd be silly to wait on getting those things upstream before making rkt more visible.
2023-07-30modules/rkt: first stab at scene editing for scenerVito Caputo
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.
2023-07-28modules/rkt: minor error message formatting fixVito Caputo
Better spearate the generic error line from surrounding text with an extra newline
2023-07-28modules/rkt: s/_EDITSCENE/_SCENE/Vito Caputo
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.
2023-07-25modules/rkt: fix vestigial til_str_newf() useVito Caputo
This is leftover from development when it used a fmt string in combination with the key, before the desc path was getting properly appended.
2023-07-17modules/rkt: limit Rocket reconnect frequency to 2HZVito Caputo
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.
2023-07-16modules/rkt: pause on entering scene 99999Vito Caputo
This is only relevant to creative mode. Stops RocketEditor from continuing playback endlessly until user intervention beyond the current end of the demo.
2023-07-16modules/rkt: track last scene in ctxt->last_sceneVito Caputo
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.
2023-07-16modules/rkt: cleanup Rocket track namesVito Caputo
- 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.
2023-07-16module/rkt: pull rkt_context_t to sync_get_trackfVito Caputo
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..
2023-07-14modules/rkt: remove vestigial "/scenes" path appendVito Caputo
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
2023-07-13modules/rkt: '=' for current Rocket scene in scenerVito Caputo
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.
2023-07-13modules/rkt: include EXITED [99999] in scenes listVito Caputo
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)
2023-07-13modules/rkt: add 99999 exit scene defineVito Caputo
rkt_scener needs to know this value so define it in rkt.h and switch over all the existing 99999 instances.
2023-07-08modules/rkt: pile of __WIN32__ concessionsVito Caputo
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
2023-07-08modules/rkt: switch to inet_addr()Vito Caputo
This is available in win32, unlike inet_aton()
2023-07-07modules/rkt: cleanup some stale commentsVito Caputo
2023-07-06modules/rkt: omit unnecessary return variableVito Caputo
trivial simplification
2023-07-06modules/rkt: fix scener send error handlingVito Caputo
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!
© All Rights Reserved