summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-06-05til_util: actually enforce TIL_MAXCPUS uniformlyVito Caputo
The win32 and mach builds were free to violate this, as it's always just been a local define for putting some kind of bound on the linux "/sys/devices/system/cpu/cpuN" probing loop. But in preparation for moving TIL_MAXCPUS out to til_util.h for public consumption in sizing per-cpu arrays, it needs to actually be enforced consistently as an upper bound cap. That way everything can safely assume n_cpus won't ever exceed TIL_MAXCPUS.
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-06-03modules/rtv: plug non-snow-channel til_setup_t leakVito Caputo
Somewhere along the line this leak was created, there's been a lot of activity surrounding this stuff so it's unsurprising. A little janky surrounding the conditional on snow module, but that's just how snow is handled today - it doesn't get randomized like the other channels do.
2023-06-03til,modules/rtv: supply settings to til_module_setup_randomize()Vito Caputo
Rather than creating an orphaned settings instance private to til_module_setup_randomize(), the function now requires the settings instance be provided. The one remaining caller of this function is modules::rtv. Now that rtv is responsible for creating the settings beforehand, and the settings may be created with a path prefix, rtv gets its til_module_context_t->setup.path prefixed for all the channel settings. Another improvement is now the channel settings instance gets created from the module name as the settings string. So while it's not yet possible to sparsely specify settings with others being randomized, at least now when log_channels=on is in effect, the printed args include the top-level channel module. Having proper complete paths for the rtv channel modules is especially visible in --print-paths output FYI. An interesting test for exercising all this is: ``` $ src/rototiller --module=rtv,duration=0,context_duration=0,snow_module=none,channels=all,log_channels=on --print-pipes --defaults --go 2>/tmp/channels in another terminal: $ tail -F /tmp/channels ``` watch the chaos unfold
2023-06-03til: fix spurious empty res_arg in til_module_setup_randomize()Vito Caputo
r variable is checked for zero(success) before writing to *res_arg, but could be left uninitialized (especially in a future scenario where an incoming til_settings_t is fully populated and described).
2023-06-03til_settings: add an optional til_settings_t.prefixVito Caputo
Preparatory commit for bridging the gap separating a baked til_setup_t from a runtime-populated descendant til_settings_t like modules::rtv produces for its channels via til_module_setup_randomize(). For these currently orphaned til_settings_t instances we don't readily have access to the logical ancestor til_settings_t that was used to produce the module_context's bound til_setup_t. But we don't really need the ancestor til_settings_t, all we _really_ want is the ancestral path to prefix the orphan til_settings_t instances. So this commit introduces supplying a prefix which gets prepended to paths printed via the settings instance. A later commit will make use of this in modules::rtv when producing the settings instance passed to til_module_setup_randomize()
2023-06-03til_settings: free til_settings_t.labelVito Caputo
These were being leaked by til_esttings_free()
2023-06-03til: skip described settings in til_module_setup_randomize()Vito Caputo
Preparatory commit for when settings are supplied by caller, potentially populated and described.
2023-06-03til_settings: drop desc from til_settings_add_value()Vito Caputo
In a world where "describing" settings is an iterative process, especially post-nested-settings which are realized via the desc-applying process, it's better to not even offer desc-setting while adding a new setting. This commit just gets rid of that. The one caller that was passing a non-NULL desc to til_settings_add_value(), til_module_setup_randomize(), was redundantly doing so since the subsequent desc-processing was assigning it again anyways. Future commits will likely change til_module_setup_randomize() use a non-NULL desc for skipping desc-applying, which wouldn't even work if it was always setting the desc @ add time. That becomes necessary for partially randomizing sparsely-populated settings.
2023-06-03modules/montage: introduce tiles= setting, stop randomizingVito Caputo
Montage would randomize orphaned setting instances for the participating modules @ context create time. This not only produced montage tiles one couldn't configure via settings even if they wanted to, but it also produced partial paths due to the orphaned settings instances. With this commit montage tiles are configurable in the same way compose::layers are; a comma-separated list of modules with settings accompanying them. Randomizing is no longer performed, but if seen via something like rtv, that randomizer will operate on the regular setup machinery to produce randomized montages. One new ability delivered with tiles= is you can specify the same module repeatedly to produce a tiled display of the same thing. Those instances may have the same or different settings, it's totally controllable. This also opens up the future for more interesting things like shiftng ticks in the montage tiles... imagine showing the same module a few times in each row, but offsetting ticks into the future/past in the columns. For ticks-driven modules, you'd see the future/past frames side by side, like a flipbook effect. This leaves rtv as the only til_module_setup_randomize() caller remaining...
2023-06-03til: add exclusions to til_get_module_names()Vito Caputo
There's often a need to exclude specific modules, though it's often a hacky kludge. It's something relied upon currently for preventing dangerous recursion scenarios, which will likely get fixed up more robustly in the future.
2023-06-03til_settings,setup: introduce til_setting_spec_t.override()Vito Caputo
In situations where modules wish to alias setting values like expanding "all" -> "mod0,mod1,mod2,mod3" they need a way to intercept the value-acceptance @ desc-assignment time in the front-end. This optional override() function does just that when present in the spec. The current setting's value is passed to the override, and if what's returned differs from what was passed (by pointer value), then the current value is freed and the override takes its place. The override function is expected to _always_ return non-NULL; either the value provided, or a newly allocated value override. The override function must never free the supplied value, that's the front-end's job in applying the override. The override() must return NULL on errors, which are assumed to be limited to ENOMEM failures.
2023-06-03til: add til_get_module_names() helperVito Caputo
Composite modules that want to provide "all" aliases for modules like rtv have to construct a comma-separated string of all module names, usually filtered by some flags. This helper does just that, but it does add yet another open_memstream() user to revisit when those all get fixed up.
2023-06-03modules/compose: drop redundant til_module_t*Vito Caputo
Once til_module_context_t.module was introduced, this vestigial module member @ compose_layer_t.module became redundant. So here it's dropped in the obvious manner, but the compose_layer_t struct is retained despite only having til_module_context_t* now. This is in anticipation of future additions where compose settings may set per-layer/texture rendering behaviors (think alpha, colors, texturing toggles, etc)
2023-06-03til_settings: require value in til_settings_add_value()Vito Caputo
There doesn't seem to be a use case for inserting NULL-value settings, and it's ergonomic to assume a til_setting_t.value is always a non-NULL heap-allocated string.
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-30til: make til_module_randomize_setup() always produce a setupVito Caputo
Preparatory for required til_setup_t @ til_module_create_context() This basically brings til_module_randomize_setup() inline with til_module_setup_finalize() in that it will still produce a minimal til_setup_t even if there is no til_module_t.setup() method. A future commit will do something about the orphaned til_settings_t within til_module_randomize_setup() to get a full path on the produced setup - which will likely simultaneously bring us into a world where one can influence the randomized settings externally as well. Influenced in the sense of potentialy making some of those settings statically configured while leaving others to be (re)randomized at the time of til_module_randomize_setup() executing.
2023-05-30modules/*: utilize til_module_setup_finalize()Vito Caputo
This replaces the few ad-hoc til_module_t.setup() setup-baking callers with the new til_module_setup_finalize() which always produces a til_setup_t having an appropriate path, even when there is no til_module_t.setup() method.
2023-05-30til: add til_module_setup_finalize() helperVito Caputo
Preparatory commit for til_module_create_context() requiring setups even when there's no til_module_t.setup() method. This helper will produce the minimal til_setup_t in such cases, or hand off the task to til_module_t.setup() when present. Note the need for passing res_setting and res_desc to til_module_t.setup() despite not being a settings-construction scenario. This is because of how modules using nested settings tend to use res_setting for storing the current setting in accessing the nested instance, which must still occur even when just baking the complete setup. It's expected that any composite/meta modules utilizing other modules will use this helper to produce the baked setups, instead of the ad-hoc direct calling of til_module_t.setup() they do presently.
2023-05-30til_setup: hash til_setup_t.pathVito Caputo
Preparatory commit for deprecating til_module_context_t.path in favor of mandatory til_module_context_t.setup providing the settings-derived context path. Future commit will drop til_module_context_t.{path,path_hash}
2023-05-30til: find explicitly set experimental modulesVito Caputo
b9123bbb added describing incoming preexisting settings, but the spec's returned values omitted experimental modules. This resulted in breaking the ability to say things like --module=rkt to access the experimental rkt module despite it not showing in the interactive setup list of values. This commit includes experimental modules in the spec's values when being produced for a preexisting, undescribed setting. Restoring one's ability to access experimental modules via the CLI.
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-28modules/voronoi: make cell color randomization conditionalVito Caputo
When voronoi is overlayed the colors get sampled, so randomizing them is pointless work every frame.
2023-05-27modules/voronoi: threaded calculate_distances()Vito Caputo
This seems to work on my 2c/4t laptop and is certainly faster. But I'm not being careful about using atomics loading/storing the d->cell pointer, which seems problematic. Surprisingly things aren't crashing here despite that, maybe on a non-x86 smp box it'd be a different story.
2023-05-27modules/voronoi: split voronoi_calculate_distances()Vito Caputo
Preparatory commit for doing the voronoi distance calculations in parallel when possible, as part of render_fragment() instead of all in prepare_frame(). Not all of the distance calculation work can easily be threaded, but it should be possible to compute the post-seed distances concurrently within the spatial bounds of the tiled fragment. This commit doesn't actually change anything functionally, as it's just splitting the old voronoi_calculate_distances() into two and calling them both in succession still from voronoi_prepare_frame(). Subsequent commits will work towards making the render_pass() fragment-aware then ultimately moved to voronoi_render_fragment()
2023-05-27modules/voronoi: remove dirty= setting and variantVito Caputo
This variant is kind of a broken hack, and its brokenness becomes more apparent in a threaded voronoi world. So just drop it for now. I am interested in more voronoi variants, but they can't compromise correctness/introduce instabilities or significantly interfere with performance improvements like threaded rendering. The dithered-ish look of dirty=on was an interesting variant though... bummer.
2023-05-27modules/voronoi: constify til_fb_fragment_tVito Caputo
trivial change; voronoi_sample_colors() only reads from the fragment
2023-05-27modules/rtv: desc the snow_module name settingVito Caputo
Like modules/checkers required for fill_module, we need to do the same for for rtv::snow_module. There's more work to do on rtv::channels, but that's still unsettled stuff in terms of settings syntax since rtv randomizes settings. It's desirable to have the rtv settings able to specify which settings to hold constant at a specific value per-channel, leaving everything else for randomizing on channel switch. But there's no syntax for that kind of stuff currently, and it seems like there's a need to communicate during the setup_func dance when we're in a "settings optional because we'll fill them in automatically at time of use later" to the front-end. It's not strictly a front-end issue though - because the back-end setup_func actually controls the forward progress. From the current setup_func's perspective, everything's important to it and must be fulfilled. And we certainly want the setup_func to continue informing the setup process. So it's more like the channel settings being populated via rtv still need to all get populated, rtv just needs a way to add an attribute to mark which settings are static vs. which should get randomized on every use. Perhaps there should just be a special value syntax reserved for saying "random value" and the front-end can apply that, but then a til_module_randomize_setup() could detect that too in a per-setting flag the front-end set. That way the value gets re-randomized, while the ones without that value set get left alone. Yes, I know this isn't the appropriate place for such commentary. But nobody is reading these things anyways on my toy side project.
2023-05-27modules/compose: trivial indentation fixupVito Caputo
2023-05-27modules/rtv: don't use n_cpus=0 for the context createsVito Caputo
This is harmless as long as rtv stays hermetic. But if rtv gets used in a composite scenario in the future by either removing the hermetic flag, or allowing forced overrides, n_cpus=0 will cause the nested module contexts to become threaded on SMP machines. That's problematic if the outer module context is already a threaded render. What's appropriate here is to just propagate the n_cpus down so if an upper layer has already gone threaded, it will be sending down n_cpus=1 to serialize the nested instances. In practice, as-is, this change basically changes nothing, but prepares for a potential future where rtv participates in threaded compositions. Through a lens of "rtv just rejiggers scenes and there settings on a timer from a settings-specified subset of modules and settings" it's arguably useful as just another module. Sometimes you want something to change itself up periodically in say a compose layer. So preparing for this possibility isn't really all that far-fetched/hypothetical.
2023-05-26setup: print paths to the settings being setupVito Caputo
This commit introduces setting path printing to interactive setup, making it much more clear what on earth you're setting up in more complex scenarios. e.g. an interactive setup of module=compose is now: ``` $ src/rototiller --module=compose /module/compose/layers: Comma-separated list of module layers, in draw-order [drizzle,stars,spiro,plato]: /module/compose/layers/[0]/drizzle/viscosity: Puddle viscosity: 0: .005 1: .01 2: .03 3: .05 Enter a value 0-3 [1 (.01)]: /module/compose/layers/[0]/drizzle/style: Overlay style: 0: mask 1: map Enter a value 0-1 [0 (mask)]: /module/compose/layers/[1]/stars/rot_adj: Rotation rate: 0: .0 1: .00001 2: .00003 3: .0001 4: .0003 5: .001 Enter a value 0-5 [2 (.00003)]: /module/compose/layers/[3]/plato/orbit_rate: Orbit rate and direction: 0: -1 1: -.75 2: -.5 3: -.25 4: .1 5: 0 6: .1 7: .25 8: .5 9: .75 10: 1 Enter a value 0-10 [7 (.25)]: /module/compose/layers/[3]/plato/spin_rate: Spin rate and direction: 0: -1 1: -.75 2: -.5 3: -.25 4: .1 5: 0 6: .1 7: .25 8: .5 9: .75 10: 1 Enter a value 0-10 [9 (.75)]: /module/compose/texture: Module to use for source texture, "none" to disable: 0: none 1: blinds 2: checkers 3: drizzle 4: julia 5: moire 6: plasma 7: roto 8: stars 9: submit 10: swab 11: voronoi Enter a value 0-11 [0 (none)]: 1 /module/compose/texture/blinds/orientation: Blinds orientation: 0: horizontal 1: vertical Enter a value 0-1 [0 (horizontal)]: /module/compose/texture/blinds/count: Blinds count: 0: 2 1: 4 2: 8 3: 12 4: 16 5: 24 6: 32 Enter a value 0-6 [4 (16)]: 3 /video: Video backend: 0: drm 1: mem 2: sdl Enter a value 0-2 [2 (sdl)]: /video/sdl/fullscreen: SDL fullscreen mode: 0: off 1: on Enter a value 0-1 [0 (off)]: /video/sdl/size: SDL window size [640x480]: Configured settings as flags: --seed=0x6471f827 '--module=compose,layers=drizzle\\\,viscosity\\\=.01\\\,style\\\=mask\,stars\\\,rot_adj\\\=.00003\,spiro\,plato\\\,orbit_rate\\\=.25\\\,spin_rate\\\=.75,texture=blinds\,orientation\=horizontal\,count\=12' '--video=sdl,fullscreen=off,size=640x480' Press enter to continue, add --go to skip this step... ``` Previously it would be like so: $ src/rototiller --module=compose Comma-separated list of module layers, in draw-order [drizzle,stars,spiro,plato]: Puddle viscosity: 0: .005 1: .01 2: .03 3: .05 Enter a value 0-3 [1 (.01)]: Overlay style: 0: mask 1: map Enter a value 0-1 [0 (mask)]: Rotation rate: 0: .0 1: .00001 2: .00003 3: .0001 4: .0003 5: .001 Enter a value 0-5 [2 (.00003)]: Orbit rate and direction: 0: -1 1: -.75 2: -.5 3: -.25 4: .1 5: 0 6: .1 7: .25 8: .5 9: .75 10: 1 Enter a value 0-10 [7 (.25)]: Spin rate and direction: 0: -1 1: -.75 2: -.5 3: -.25 4: .1 5: 0 6: .1 7: .25 8: .5 9: .75 10: 1 Enter a value 0-10 [9 (.75)]: Module to use for source texture, "none" to disable: 0: none 1: blinds 2: checkers 3: drizzle 4: julia 5: moire 6: plasma 7: roto 8: stars 9: submit 10: swab 11: voronoi Enter a value 0-11 [0 (none)]: 1 Blinds orientation: 0: horizontal 1: vertical Enter a value 0-1 [0 (horizontal)]: Blinds count: 0: 2 1: 4 2: 8 3: 12 4: 16 5: 24 6: 32 Enter a value 0-6 [4 (16)]: 3 Video backend: 0: drm 1: mem 2: sdl Enter a value 0-2 [2 (sdl)]: SDL fullscreen mode: 0: off 1: on Enter a value 0-1 [0 (off)]: SDL window size [640x480]: Configured settings as flags: --seed=0x6471f827 '--module=compose,layers=drizzle\\\,viscosity\\\=.01\\\,style\\\=mask\,stars\\\,rot_adj\\\=.00003\,spiro\,plato\\\,orbit_rate\\\=.25\\\,spin_rate\\\=.75,texture=blinds\,orientation\=horizontal\,count\=12' '--video=sdl,fullscreen=off,size=640x480' Press enter to continue, add --go to skip this step... ``` Which gets rather confusing, especially if you go even deeper with nested module situations like compose/layers/[0]/checkers/fill_module/compose/layers/[0]/drizzle You just lose track of which module instance's settings you're actually setting up This is just the first step of making use of these paths. In the future the module context paths will be derived from the settings paths so they're more reliably distinct and descriptive, along with consistent with paths in the settings namespace. That becomes important when module contexts start getting registered on the stream for use in other modules.
2023-05-26til_settings: add some settings and desc path printersVito Caputo
These print to a stdio FILE*, which for now is harmless since setup_interactively() will be the only consumer (... for now). If one needed the path in a buffer, they could use open_memstream() and pass that FILE* to the printers. And since commit 40feb61 there's already a dependency on the function, but it's icky to dig deeper into that portability trap. Although it seemed like rototiller actually compiled on MacOS at Gene's house, so maybe open_memstream() isn't as problematic as it once was. Anywhow, this commit only adds the path printing helpers, nothing is using them yet.
2023-05-26til_settings: add til_setting_spec_t.as_labelVito Caputo
Currently settings instances get labels from three sources: 1. explicitly labeled by a root-level til_settings_new() call, like main.c::til_settings_new(NULL, "video", args->video); 2. implicitly labeled in a spec.as_nested_settings w/spec.key 3. positionally labeled in a spec.as_nested_settings w/o spec.key But when constructing setting/desc paths, using strictly these settings instance labels as the "directory name path component" equivalent, leaves something to be desired. Take this hypothetical module setting path for example: /module/layers/[0]/viscosity Strictly using settings instance labels as-is, the above is what you'd get for the drizzle::viscosity setting in something like: --module=compose,layers=drizzle Which is really awkward. What's really desired is more like: /module/compose/layers/[0]/drizzle/viscosity Now one way to achieve that is to just create more settings instances to hold these module names as labels and things would Just Work more or less. But that would be rather annoying and heavyweight, when what's _really_ wanted is a way to turn the first entry's value of a given setting instance into a sort of synthetic directory component in the path. So that's what this commit does. When a spec has .as_label specified, it's saying that path construction should treat this setting's value as if it were a label on a settings instance. But it's special cased to only apply to descs hanging off the first entry of a settings instance, as that's the only scenario we're making use of, and it avoids having to do crazy things like search all the entries for specs w/.as_label set. It feels a bit janky but it does achieve what's needed with little pain/churn.
2023-05-26til: more setup desc handling fixupsVito Caputo
7ff8ef94 switched things to always describe relevant settings, but left some loose ends. Obvious fixups for those
2023-05-26setup,til: assert(desc) if setup_func() wants more settingsVito Caputo
In this "all settings require descs" world, when setup_func forgets to return a res_desc for a setting it wants, we can end up in an infinite loop situation. It's better to abort immediately on the assert to catch such a program error.
2023-05-26modules/compose: desc the layer and texture module name settingsVito Caputo
Like modules/checkers required for fill_module, we need to do the same for for compose. It's a little more weird in compose since compose::layers is a nested settings full of unnamed nested settings. But compose::texture is analogous to checkers::fill_module.
2023-05-26modules/checkers: desc the fill_module's name settingVito Caputo
The bare-value value_as_nested_settings.entries[0] setting which serves as the name for module lookup is in a sort of no-mans land between checkers and the underlying fill_module's setup. So we have to do this little bit of rigamarole in checkers, being the entity wiring up the nested module. The fill_module's setup_func won't be doing anything to describe the name's setting as it's only interested in its own settings. There will likely be some helpers made later to streamline this process of composing module/settings hierarchies.
2023-05-26til_settings: drop settings->label from generated labelVito Caputo
Since these are ultimately intended for use in path construction, it's redundant to include the settings->label in the generated label. Instead what's really useful is just the subscript part: /module/compose/layers/layers[0]/drizzle/viscosity Becomes: /module/compose/layers/[0]/drizzle/viscosity which is far better. It may seem silly to have both the positional subscript *and* the module name, as in why not just have: /module/compose/layers/drizzle/viscosity But there's a need ot handle potential collisions like so: /module/compose/layers/[0]/drizzle/viscosity /module/compose/layers/[1]/stars /module/compose/layers/[2]/drizzle/viscosity So then maybe you think; ok, why have the module name? just use the positional subscript since that alone prevents the collisions. Result: /module/compose/layers/[0]/viscosity ... /module/compose/layers/[2]/viscosity Well, now we've lost useful context. The viscosity setting recurs on multiple modules, and we don't know just at a glance what we're working with anymore. Hence, why there's both. The module name in the path makes things substantially more self-explanatory. These paths will likely be what you're looking at as the labels of tracks in a multitrack sequencer like GNU Rocket. So this decision is likely affecting the UX at that level in the fullness of time.
2023-05-26setup: remove vestigial key-as-value printVito Caputo
Since 1a8abe80dabd this ceased to be the right thing to do, since there's no longer the whole bare-key setting with null value. It's now always a value, and the key that's optional.
2023-05-24til_settings: til_setting_t,til_settings_t get parent pointersVito Caputo
Preparatory for constructing unique paths from a given setting/settings instance by walking up the tree
2023-05-23modules/rtv: log_channels s/{yes,no}/{on,off}/Vito Caputo
Using on/off for boolean settings is the established convention in rototiller, rtv went rogue here. Just make it consistent Sometimes it feels like this should be more flexible and support 0/1 yes/no true/false on/off by just having "boolean" typed settings. But I think it may actually pay off long-term to be so opinionated here and making serialized settings heirarchies directly hashable/comparable without major normalization steps (nothing beyond say... case normalization).
2023-05-23libs/sig: mechanical rename sig_t->sig_sig_tVito Caputo
sig_t collides with some signals-related system header on macos. Just prefix it under the sig namespace.. leaving sig_ops alone for now, but maybe they'll become sig_sig_ops in the future too. Note nothing in master actually uses libs/sig currently, but I have an experimental branch with a dusty module using it.
2023-05-23util: add macos support for getting number of CPUsVito Caputo
Without this mac builds w/brew must be falling through the single CPU default linux failure code.
2023-05-23modules/checkers: add seed to randomized pattern,dynamicsVito Caputo
this oversight becomes apparent when stacking checkers as compose layers w/random pattern and/or dynamics. The stacked instances would identical pseudo-random behaviors for lack of seeding.
© All Rights Reserved