summaryrefslogtreecommitdiff
path: root/src/til_stream.c
AgeCommit message (Collapse)Author
2023-06-12til_stream: introduce on-stream registered contextsVito Caputo
In order for modules like rkt to be able to do integrated transitions, there must be a way for discovering existing module contexts by path and using them for rendering in new compositions. This is a first stab at something along those lines. The whole multiple contexts at the same path pattern has been partially handled in this implementation, but I think it will just be going away and checkers::fill_module refactored to not do that.
2023-06-08til_stream: name pipe-oriented stream api as suchVito Caputo
When all the stream encapsulated were pipes/taps, naming was less precise. With module contexts in the process of being registered in the stream, there's a need to distinguish things more. This is a largely mechanical naming change...
2023-06-06til_stream: drop redundant til_stream_pipe_t typedefVito Caputo
This is already in the header
2023-06-05til_stream: s/buckets/pipe_buckets/Vito Caputo
Mechanical rename in preparation for context buckets for hashing all contexts existing on a stream.
2023-01-21til_stream: introduce til_stream_hooks_t et alVito Caputo
There needs to be a way for a meta module like rocket to take ownership of pipes immediately upon instantiation. Since the pipes are created on demand as they become tapped by the modules using htem, the simplest way to do this is to register some callbacks with the ability to intercept the pipe creation in terms of ownership and driving tap control etc. This commit forms a minimal implementation of that, with the ability to have a single intercepter hooked into a given stream. It's a first-come-first-served situation, but that should suffice for now since the rocket meta module would be the entrypoint for such constructions. It then calls into another module to produce on the stream, after it'll already have its hooks registered. There might be a need for stacking hooks to let multiple modules control pipes. GNU Rocket for instance only deals with floats/doubles, and doesn't make it particularly easy to work on higher order concepts like say orbiting a vector around a point spatially. It might make sense to allow compositing of editors where there's rocket controlling the simple floats, and another doing dimensional/spatial stuff, with separate stacked meta modules accomodating those editors. But that's putting the cart before the horse, let's do the stupid simple thing for now and see what this is like.
2023-01-21til_stream: teardown pipes when the driving_tap's owner matchesVito Caputo
The driving tap's owner and pipe's owner are decoupled. When tearing down an owner from a stream, any pipes its taps are driving should also just go away. Otherwise its taps could linger on pipes it doesn't own, which would be a UAF bug. If the pipe is still needed, it'll just get recreated by another tap. So there's a small perf hit, but this shouldn't be a continuos kind of occurrence.
2023-01-21til_stream: minor cosmetic naming/comments fixesVito Caputo
Some clarifications
2023-01-21til_stream: add til_stream_pipe_set_driving_tap()Vito Caputo
2023-01-21til_{tap,stream}: introduce til_tap_t.inactiveVito Caputo
When a driving tap becomes inactive, til_stream_tap() should be able to notice and replace the driver. An example driving tap becoming inactive would be a GNU Rocket track that once had keys in it, but then had them all deleted. This should set the inactive flag so the tap's automation can take over. This gives the user at the Rocket editor the ability to both take over from the tap automation and surrender control back, by populating vs. emptying the respective track.
2023-01-21til_stream: introduce stream iterator et alVito Caputo
In order to implement something like a rocket module there needs to be a way to iterate the pipes in the stream, and take owernship of them when not already owned by rocket. The way rocket's API works is you lookup tracks by name at runtime. The rocket module will be a meta module that calls into another module for rendering, arbitrarily configured via a rocket setting a la checkers::fill_module. So it won't be until the underlying modules do some rendering that their taps get their respective pipes established in the stream. Then the rocket module can look at all the pipes and for any it doesn't own yet, it can get the tracks for those names and take ownership while stowing the track handle in owner_foo for the pipe. While iterating all the pipes, the pipes already owned will have the tracks readily available which can produce the values to stick in the tap. Something like that anyways, the til_stream_t api changes in this commit are all preparatory for a rocket module.
2023-01-21til_stream: comment fix, and assert/error on mismatchVito Caputo
Just clarify some verbiage, and actually assert type+n_elems match. Note mismatch also fallsthrough to an -EINVAL just in case asserts() have been compiled out (-DNDEBUG).
2023-01-21til_stream: add a second void* to til_stream_pipe_tVito Caputo
It seems likely that pipe owners will need not only a way to differentiate themselves via the owner pointer, but also somewhere to register a pipe-specific reference. There probably needs to be a result pointer added for storing the owner_foo when the owner taps, so the owner can make use of it.
2023-01-11til_{stream,tap}: add GPL headersVito Caputo
Just some banal paperwork...
2023-01-11til_stream: first stab at implementing til_stream_tVito Caputo
Until now there's just been a forward declared type for til_fb_fragment_t.stream's type, and it's been completely unused. The purpose of the stream is to provide a continous inter-frame object where information can be stored pertaining to the stream of frames. Right now, that information is limited to emergent "pipes" formed by using taps against a given stream. Taps at new paths in the stream become added as pipes for those paths, with the responsible tap hooked in as the driving tap. Taps at existing paths become diverted to the driving taps, enabling potential for external drivers for tapped variables. This commit only adds the implementation, nothing is actually using it yet.
© All Rights Reserved