A live-coding lighting controller, building on the Open Lighting Architecture with Clojure and bits of Overtone.
brunchboy on main
Fix embedded user guide build c… (compare)
brunchboy on main
Fix link alt text [skip ci] (compare)
brunchboy on main
Update chat links to Zulip. (compare)
brunchboy on master
brunchboy on main
brunchboy on master
Upgrade to antora 3, lunr exten… (compare)
brunchboy on master
Fix license badge [skip ci] (compare)
brunchboy on main
Fix license badge [skip ci] (compare)
brunchboy on main
Fix license badge [skip ci] (compare)
brunchboy on master
Fix logo for dark mode on GitHu… (compare)
brunchboy on master
Fix logo for dark mode on GitHu… (compare)
brunchboy on main
Fix license badge [skip ci] (compare)
brunchboy on main
Upgrade license, fix logo for d… (compare)
:variables (cue-vars :beats :cycles "blue" (alter-start :fraction 0.3) (make-var ["spread" 0 -45 45] :centered true))
. Also visualising lfos in color-fn, and other stuff to make things purrdy. https://drive.google.com/file/d/1lzsd1oeS7GcE4vRCeli0u_HHXRRgYdoG/view?usp=sharing
oi sounds fucking awesome hey! First thought: "oh wow so beat-link allows for two-way comm-" bashes own head in how else would it work ugh... hahah. Stay on it!
Anyways now that I'm no longer literally the worst at clojure, and have made some stuff to make the only game in clojure-bound repl-based live coding dmx controllers slightly less of a PITA, I can confirm that the path I could already sense back when I knew what (((lisp))) was, if not how to stake it, is if anything even shorter than I thought. Basically I'm seeing (build-dot-app #(create-app :name %1, :config (parse (str %1 '.cfg))
:interfacing (into [:dmx :midi :beat-link]
(condp = %1
"Glow" [:beyond :osc :max-msp]
"pixTol" [:live :resolume :mqtt :libmapper :quil :wavetick :allthecoolstuffreally]
%2))))
["YOURAPPHERE"] [[:FANCYEXTRAS]]
or like, yeah.
Basically afterglow is 90% a packageable app, decent helpers take it 90% the rest of the way, and at that point there's so little input data required it might as well come from a text file or even config page, also being yer first-run web interface (with rdm through OLA!)... nahmean?
And whatwith how fancy the general interfacin', exposure (200+ stars and one confirmed actual long-time (after almost a year finally not mostly just struggling!) user has to be some sort of record...) and whatnot you already got -> so long ghost town
({add,remove}-{device,control,note}-mapping)
instead of ({add,remove}-mapping [... & {:keys [kind]}] ...(route kind...)
map
bang your mom halfway into writing afterglow, or something?(> (fx/dimmer) (do (... refer dimmer-effect) (dimmer-effect)))
.(apply-vm vm ...)
better than (apply-merging-var-map var-map ...)
. Of course current state doesn't ask more of the end user than wrapping some stuff up and making a bunch of refers and defs, but from a reusability, code contribution, etc standpoint I feel it'd be much better to keep it as lean as possible in the first place, with minimal fn names often reused in many different places, which you seem rather keen to avoid with all the effects/...-effect, params/...-param, but surely more a strength than weakness when delineated by namespace (cue/%, fx/%, p/% [color, dimmer, lfo, ...] is pretty great when trying to make stuff streamlined and generic). Then it's all easy enough on the fingers in the first place that neither refers nor defs tempt at all, and it just becomes about matching up the :as
s up top. Right? :let [{:keys [ult] :as s} (mapv %1 [due time is] '[\ ", " .])]]
(%2 %1 (get-in s ult))) [str apply]))`
:refer
for readability reasons, and I was moving along that path in writing this, I’m sure. The examples namespace is a horrible mess of things I threw in there as I was experimenting with them; I have cleaned it up a little, but it is nowhere near friendly yet.