I'm working on a piece about how the free software movement's first principle "freedom to run the program for any purpose" is a flawed definition of freedom - only taking into account the individual.
Emma Goldman has a good critique of this, but curious if there are other philosophical and theoretical arguments around the concept of "freedom" I should source.
I made a new #BugFix release in the #KF 2.14 branch, hopefully the last one unless ppl complain about more bugs; focusing on getting 2.15 in a fit state to release now...
- assertion failure loading some formulas (reported by panzerboy)
- bailout iteration count is reset to 1000 when zooming in quickly after toggling fullscreen (reported by FK68)
- guessing exterior gives poor quality images (reported by PrinceOfCreation)
- crash when zooming too quickly near interior black regions (reported by Foxxie) (may have already been fixed in an earlier version)
- speckles when rendering zoom out sequence (may have already been fixed in an earlier version)
* library upgrades
- upgrade to boost 1.74.0
- upgrade to openexr 2.5.3
- upgrade compiler to g++-mingw-w64 10.1.0-3+23 (Debian Bullseye/testing) and rebuild everything
I released #zoomasm version 1.0 "felicitats" yesterday. It's a tool for assembling #fractal #zoom #animation #video from exponential strip keyframes with RGB and/or raw iteration data in EXR format - the colouring is controlled by an #OpenGL #GLSL #fragment #shader snippet with a few presets included (or write your own).
(However, the only software I know of that can export keyframes for input to zoomasm, is #kf 2.15 branch which is not yet released... so getting that done is my new focus.)
> Cousin Silas & Friends volume 8 part 3 (waag_rel141)
> CC By-NC-ND
> ambient, electronic
Liking this release a lot.
I implemented (hopefully #monotone) #cubic #interpolation, as well as linear and step modes, for #zoom depth #animation in my #zoomasm tool for assembling #fractal animations from exponential strip keyframes. Much smoother than the piecewise linear that was the only option before (no more speed discontinuities at waypoints, unless you want them).
It's a group-address at https://gup.pe which overcomes insularity of fediverse instances causing hashtags not working well locally especially on small instances.
If you are interested in posts in the group just follow it like you would any other user on fedi.
Please boost this widely!
C++ threads in MINGW64
I finally figured out how to get C++ std::thread and friends to work in mingw64 cross-compiling for Windows from Linux (Debian Bullseye). Turns out you can either use the -win32 threading model without native std::thread and use mingw-std-threads 3rd party implementation, or use the -posix variant and everything works just fine when you link pthread at the end.
Setting the -posix C++ compiler in every ./configure thing seems to be a bit very awkward, but Debian has a global config for it:
sudo update-alternatives --config x86_64-w64-mingw32-g++
# select posix variant in the dialog
export LDFLAGS="-static-libgcc -static-libstdc++ -Wl,-Bstatic -lpthread -Wl,-Bdynamic"
# delete all code patches referencing mingw-std-threads
# recompile everything (mixing variants might crash? dunno...)
#stinktober 1st, freshly brewed filter coffee this morning
Made steady progress this morning:
- option to poll colouring shader file for changes and automatically recompile, keeping the last successfully compiled #shader to avoid blank screen. allows simple #livecoding by hitting save in your favourite text editor
- checkboxes to choose which EXR keyframe channels to upload to the GPU. defaults to all of them, unless they would exceed the detected VRAM capacity, in which case they are all disabled and you can enable them manually. there's an option to override this behaviour and force uploading channels even if it would exceed VRAM capacity, might be useful if it is misdetected?
- time display in recording progress dialog: elapsed time (accurate) and estimated time to completion (at least on my laptop, this is not accurate until the last few seconds as recording seems to slow down over time...)
Only 16 items left on my to do list for zoomasm-1.0! Some of them are probably quite hard/involved though...
Today's progress was mainly on adding relatively small features and fixing minor annoyances:
32cbc28 minor fixes
fc1c737 add tooltips; rename a few things
b181e8a don't limit final recording speed to display vsync
da2081a fixme note
dac98dc make default website theme light
ccb49c6 set output video CRF (including lossless/incompatible)
7e44c6a output option audio bitrate (kbps, plus Copy option)
4ccca29 report estimated VRAM usage
4b72a3a move status and record button from timeline to output
22f1569 press Return to add a new waypoint
Once these todos are done, I'll finish up kf 2.15 so there's actually a released program that can create input for zoomasm.
Oriented box signed distance function from Inigo Quilez:
Segments activated by a load of conditionals on each digit's value.
Digits found by repeated divmod 10 stuff, after multiplying by 10000 (sets maximum number of digits after the point).
Leading zeros stripped with a simple loop (that stops at the point). I have code to strip trailing zeros too, but changing values are seldom affected.
Anti-aliasing of the decimal point seems to be a bit off, looks a bit too blurry. Want to add an option to move it to the baseline too.
Currently there are controls for glyph size, point size, segment length, segment thickness, foreground and background colours.
Eventual aim is to port the number rendering to the zoom video assembler I've been working on, to display zoom depth. Will need some extra fiddling, as that needs to be in log-domain and expanded to scientific notation without overflow.
Need to add motion blur to the zoom assembler first, otherwise the least significant digits will be too stroboscopic.
making art with maths and algorithms
Welcome to post.lurk.org, an instance for discussions around cultural freedom, experimental, new media art, net and computational culture, and things like that.