It has been a few less-nudel / nudel-free weeks for me at the start of this year. I need to to more of it again!
Probably due to having a full calendar. But I really do need to get time strudel experience now that I actually am giving a curse for live coding in the summer! :D (it’s gonna be fiiiine)

I also should look into other visual generating languages. I feel like they are approaches out there that I currently don’t just because I stuck with the hydra way of thinking for now.

Which is very canvas based, I imagine there is at least an „element based“ approach? (Please give me pointers!)

@reckter Processing (and its descendant p5.js) seem "element based"?

SDFs (in shaders) are also a cool way to deal with 2d/3d elements, and boolean combinations of them, while still having the same "per-pixel powers" that Hydra provides. Shadertoy has a lot of cool examples, an "SDF engine" doesn't require much code.

See also:

3d SDFs: https://iquilezles.org/articles/distfunctions/

2d SDFs: https://iquilezles.org/articles/distfunctions2d/

@reckter tooting my own horn a bit, but improviz works more in the processing style "element based" approach (never thought of it like that before but it's a pretty good phrase)
https://codeberg.org/rumblesan/improviz

Also very worth looking at the stuff Sarah GHP does with la habra and olio
https://github.com/sarahghp/la-habra
https://gitlab.com/sarahghp/olio

And definitely Charlie Roberts marching js
https://charlieroberts.github.io/marching/

improviz

DEPRECATED: A live-coded visual performance tool

Codeberg.org
@reckter will have a think any other live coding visuals that are dissimilar to hydra. Feel like some of the pure data/gem stuff @hellocatfood has done will probably fall into this category

@rumblesan @reckter I recently recommended a few environments for visuals https://post.lurk.org/@hellocatfood/115963002271707605

Coollab an cables_gl are definitely ones to look into, in particular as cables_gl can be web based

hellocatfood (@[email protected])

@[email protected] For sure! And there's even image editors with node interfaces like Graphite https://github.com/GraphiteEditor/Graphite PixiEditor https://pixieditor.net/ Rasterflow https://rasterflow.io/ Natron https://natrongithub.github.io/ It's a good day for nodes.

post.lurk.org
@rumblesan ah I've seen @sarahghp (or @sarahghp ?) gve a talk at @alpaca2025 ! olio is such a quirky little tool, loved it!

@reckter I mean I hate to say “my one”, but… my one?

https://flitter.readthedocs.io/en/latest/

It has been described as “artisanal”. I would say it is very much designed to work the way I think, and so is likely to be of only academic interest.

Flitter — Flitter documentation

@jonathanhogg ah yes! I remember your talk from alpaca as well :D
I think it goes into the direction I was thinking of :D
@reckter you might also be interested in @michael’s ocaml graphics library. Talk by him on it here: https://youtu.be/2ZswyN4aP2o but I expect he has some links somewhere… [edit: wrong handle for Michael]
Learning OCaml with Tiny Code Xmas - Michael Dales - FUN OCaml 2024

YouTube

@jonathanhogg @reckter Thanks for the hat tip Jonathan! Claudius isn't element based per-se, but the way I use it might be considered as such. I like to make functional pipelines of each time tick: take initial elements -> apply a time based transform -> apply a 3D to 2D transform (if that's the thing) -> apply a abstract node to rendering command

I very much enjoy that sort of functional/declarative approach. But the element part of that is more something I do per demo, eventually compiling to a list of Point or Line objects the drawing library I wrote understands.