I see very nasty GPU bugs on this page. never witnessed it before. My laptop is macbook m3. I managed to record them https://youtu.be/9EpfeUbkPT8
Thi.ng – open-source building blocks for computational design and art
31–39 of 39 posts
Re: Thi.ng – open-source building blocks for computational design and art
#32[flagged]
#2 This is potentially a Safari bug with interactive SVGs on iOS. JS usage on this site is minimal.
Re: Thi.ng – open-source building blocks for computational design and art
#33Is that monorepo heat map visualisation also reproducible for other repos? It kicks ass
Re: Thi.ng – open-source building blocks for computational design and art
#34I believe the new libs are now all in TS and not Clojure anymore. Does that mean TS is better suited for computational art? Or are there other reasons why this lib was moved to TS?
> Or are there other reasons why this lib was moved to TS? I'm pretty sure reach was the motivation. The author basically wrote his own TypeScript libraries duplicating a bunch of Clojure stuff, so the code is quite Clojure-like still.
Re: Thi.ng – open-source building blocks for computational design and art
#35This has been around for a long time and I've always been so surprised it has had seemingly so little traction outside of the author's own projects. The love and care and thoughtfulness of every library has always been so great to explore.
I love karsten and have been following his work for a long long time. Used/Use his old toxiclibs library extensively both in processing and java. Have ported parts of it to golang for personal use. I want to say he also had some librarys for openframeworks/c++ and I probably used those as well (it was perhaps someone elses rough port of toxic to c++). Originally I bounced off this because of clojure, it just wasn't w…
Re: Thi.ng – open-source building blocks for computational design and art
#36Earlier quoted context omitted.
You can find his talk about it a bit on Twitter and in the Github issues. But as far as I remember it mostly boils down to the fact that thing/geom got very little traction and external contributions. He developed this huge ecosystem on his own to make digital art but it wasn't being really picked up by others. Digital art is typically quite collaborative with people giving workshops and stuff. The switch to TS was s…
Author here. The move to TypeScript was due to multiple reasons, one of them as you mentioned. In these early years, there were very few people in the Clojure community which had an interest in these topics (general visualization/geometry related), and which wasn't just about art btw. Still, I managed to teach a dozen or so workshops from 2011-2017 and form a small community. In hindsight, Clojure/ClojureScript took…
- OpenCL interop (e.g. https://thi.ng/raymarchcl, https://thi.ng/simplecl)
- GLSL (e.g. https://thi.ng/shader-ast)
- C11 (e.g. https://github.com/thi-ng/c-thing, https://thi.ng/synstack)
- Zig (https://github.com/thi-ng/zig-thing)
- WASM (https://thi.ng/wasm-api)
- Forth (https://thi.ng/charlie)
There are infrastructure packages to simplify creation of ad hoc DSLs, their transpilation or interpretation, but also interop with WASM (so far mostly geared towards & tested with Zig), for example:
In general, thi.ng projects range from super high level computational design concepts to low-level primitives like memory allocators and memory/data layout management (e.g. https://thi.ng/tinyalloc, https://thi.ng/malloc, https://thi.ng/simd, https://thi.ng/soa) and a huge spectrum of other things in between...
Re: Thi.ng – open-source building blocks for computational design and art
#37Earlier quoted context omitted.
I love karsten and have been following his work for a long long time. Used/Use his old toxiclibs library extensively both in processing and java. Have ported parts of it to golang for personal use. I want to say he also had some librarys for openframeworks/c++ and I probably used those as well (it was perhaps someone elses rough port of toxic to c++). Originally I bounced off this because of clojure, it just wasn't w…
Thanks, Brett! <3 :)
Re: Thi.ng – open-source building blocks for computational design and art
#38Earlier quoted context omitted.
You can find his talk about it a bit on Twitter and in the Github issues. But as far as I remember it mostly boils down to the fact that thing/geom got very little traction and external contributions. He developed this huge ecosystem on his own to make digital art but it wasn't being really picked up by others. Digital art is typically quite collaborative with people giving workshops and stuff. The switch to TS was s…
Author here. The move to TypeScript was due to multiple reasons, one of them as you mentioned. In these early years, there were very few people in the Clojure community which had an interest in these topics (general visualization/geometry related), and which wasn't just about art btw. Still, I managed to teach a dozen or so workshops from 2011-2017 and form a small community. In hindsight, Clojure/ClojureScript took…
I real liked the orgmode workflow b/c the code was self documenting in a sense. I had a very similar workflow for many years (though I've since stopped) But I do remember that in the leiningen days when I was first learning Clojure, the idea of tangling and attaching my own fork was just too intimidating and confusing. With the deps.edn workflow it'd have been less of a hassle now
Thank you for all your work. I still used geom basically every week (generating graphics for my PhD)
Your blog post is great. I think your point about the silo'ing and lack of cross pollination of idea between langs/frameworks is interesting, but also a product of just time-investment. I used to code C++ and the C++ gurus were always very miopic b/c they simply had no time for anything else.
To the last idea, I feel the ease of creating and having performance available is always in tension. I have a friend who works in Touchdesigner and I'm always left a bit embarrassed that no written programming language seems to hit the same level of productivity. Going down the stack can be fruitful, but I think there are still more levels of abstraction that need to be explored. At a high level.. even if you're writing immutable functional code.. it just all still feels too coupled to me. These days, I'm personally think the next step is something like Pathom. Where your declare decoupled relationships between inputs and outputs and have a engine derive your computation.
Re: Thi.ng – open-source building blocks for computational design and art
#39[flagged]