A live-coding lighting controller, building on the Open Lighting Architecture with Clojure and bits of Overtone.
As for me, almost no clj/afterglow past few months :( full focus on making my device/firmware design proper robust and modular/IO agnostic, with it its own lil rendering loop of adjustable effects working incoming pixel data...
Still all about using afterglow as a hub: running trad fixtures, providing ctrl data for the strips, interfacing with Max<->Live for sequencing etc.
But scaling up, animation data is simply (and unsurprisingly) better sourced from existing, purpose-built and performance-optimised tools - jitter, madmapper, whatnot.
But since I’m not a real programmer, just trying to become one (soon enough, if I can keep up my current learning curve), last having used c++ way back in high school... the finer points of it are proving... tricky ;) Still, cool shit in the pipe for sure.
Point of spiel: @James could I maybe catch you on skype some time? Got lots of questions and something of a pitch for you.
Sorry @brunchboy lol
Hey, @tolgraven thanks so much for helping out, your answers had already steered @NHGmaniac in the right direction before I even was notified that there was discussion happening here! We can try to figure out a Skype session sometime, but we’ll have to schedule it because I only use the application every couple of years. It will have to be after this weekend, though, because I am about to travel to Canada for the music festival where I’m meeting some of my most creative and enthusiastic users of Beat Link Trigger, and will be able to see how they use it in production and get new ideas. :grinning:
Fair play! And very glad to hear you’re getting (much well-deserved I was gonna say, but that would be an almost criminal understatement haha) user uptake for other open source projects :) sorta begs the question tho, if you yourself barely use afterglow, and it must’ve been a given it’d always be very niche, how did you find the time and energy to make it so complete and incredibly polished?
Thanks so much! I’m confined to my phone for the next few days so I’ll write less, but I’m delighted that you have looked deeply enough into afterglow to see such details, and that you feel this way. It is a project that perfectly combined many of my passions and obsessions, and even though life is too busy right now for us to find and stage the kind of gigs that would benefit from it while working full time in my challenging and interesting day job, I do hope to someday connect with a lighting designer and venue who is willing to experiment with this approach and collaborate on taking it further.
it's just a very small act, and it was a spontaneus decision, but it's a lot of fun https://sozial.derguhl.de/media/581cb934-470b-44a7-92f3-8e1014c9a1a4/Tusky_1528497353695_LUZ7FIU8YV.mp4
Alright so the modifications I've made so far to afterglow proper are probably way too specific to me to be any general use, but I now have lots and lots of likely fairly useful code for the front end, to generate maps of variables for cues, creating lfos and other params from those vars, and creating pages of cues from all of that. Very much needed I reckon, since the current state of the example file probably scares off both those versed in, and those unfamiliar with lisps, in equal amounts... Question is how to incorporate it. If I put it up do you have time to go through it and help break it up into a few sensible namespaces?
so instead of a massive raw vector of maps for each damn cue it's maybe like
: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
This is very exciting, Joen, I am so glad that you are making such progress in exploring afterglow! I am extremely busy right now trying to finish of a major new feature in Beat Link Trigger, which will allow people to synchronize Pioneer CDJs to other music being played by any application or device that supports the Ableton Link protocol, so I don’t know when I will be able to focus in depth on this, but could I suggest you try writing up your new helper functions as pages on the afterglow Wiki and then as I do have time I can see about helping organize them and pull them into the actual source? As you noted, many of my existing examples are bizarre, complex, and really useful only to me as I was shaking out features in the core engine, so this sounds like it will be a great help in making it more broadly useful and accessible. Thank you so much!
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
anyways apart from the general direction that way pitch I have some ???.
- what is the deal with the code repetition? examples.clj is the worst but even something like midi there's a zillion different fns with all the same code and one differing thing. Why
({add,remove}-{device,control,note}-mapping)instead of({add,remove}-mapping [... & {:keys [kind]}] ...(route kind...)
In the same sense the dissonance between the neat protocols of effects.clj and the implementations in fun.clj (and let's not even get into the effects in examples) is... didmapbang your mom halfway into writing afterglow, or something? - fn names, esp relating to ns's. Aren't 90% of them way verbose for anything live? And a lot of the time it's like they're stuck somewhere halfway between "yeah-gotta-rebind-all-these-anyways", and "let's :refer the lot".
(> (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:ass up top. Right? - having recently dusted off brave&true one last time I felt inspired to whip this up.
`(rand-nth (apply #(for [time ["atrocious" "unbecoming" "not functional"] is '[man brah fam] due '[damn tots quite]:let [{:keys [ult] :as s} (mapv %1 [due time is] '[\ ", " .])]] (%2 %1 (get-in s ult))) [str apply]))`
def don't mean to come off as combative, honestly curious :)
You aren’t coming off as combative at all, don’t worry! I don’t remember the full answers right now, as it has been so long since I was in the code in any depth, but from a historical perspective, keep in mind that I was learning Clojure and the functional programming mindset at the same time as I was trying to figure out if writing something like this was even going to be possible, at the same time as I was trying to figure out a functional model for rendering lighting effects, and figuring out how to work with hue/saturation/value models to control RGB lighting, and wondering if it was possible to figure out the trigonometry to get light precisely where you want it given a model of your rig and the DMX response of the servos. So I am sure there is plenty of room for cleanup.
I think that it is important to have very clear code in the core of the algorithms, and then a nice concise layer can be wrapped on top of that for live coding. And frankly once I saw how cool an interface I could make on the Push (and Push 2) I started to focus more on that than the live coding aspect.
The Clojure community as a whole has moved away from
: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.
I agree, and that’s a great idea. I ran out of steam for doing the cleanup when I decided this was probably far too esoteric, and with too steep a learning curve even after cleanup, for anyone to ever try to pick it up. Now that you are proving me wrong, I am happy to get some steam back. :grinning:
I love your ideas for building a more accessible wrapper around it, and can’t wait to see where they go! This will hopefully get me back involved in coding Afterglow itself too, as soon as I can finish these Beat Link Trigger projects. (Afterglow has more stars, but BLT has thousands more downloads, by mostly non-coders who are figuring out how to create wacky integrations in their stage shows.)
As an aside, if I get back to Stockholm I would love to see the things you are doing. (I spent four years there as a young boy, and it is one of my favorite cities to visit.)
But for now, back to debugging Ableton Link -> Pioneer sync. (I’ve supported sync in the other direction for nearly as long as Ableton Link has existed, but only recently have I tried tackling the level of emulation needed to control the beat grid of the CDJ network, since that is not nearly so nicely designed as Ableton Link, nor is it documented at all, I have had to reverse-engineer the entire way.)
Awesome! Well I mean that’s what I mean is there’s so much already done in afterglow that simply streamlining stuff (for example I’m making sure all effects take the same basic params and deal with them on their end, even if they mean different things, so they all can be called from the same cue-creating function which in turn wraps each in a fade to blank = alpha/mute/solo) even if originally for the sake of easier development, also provides a clear track to easy usage and configuration for non-coders
Coincidentally I’m moving from Stockholm tomorrow haha. Or, until next summer at least
It’s great having someone else think about this and work on it. I look forward to seeing what you come up with. I hope your move went well, I hate moving. And I’ve finally had some key breakthroughs in my synchronization project, and now seem to have achieved accurate, stable sync in both directions, hurrah!
And another year passes ouch. How are you? Haven’t managed much proper interesting but past couple months I’ve been learning web design (probably about time if I’m to find work as a coder) and again using afterglow as a shiny thing to reinvent to stay on track throughout it hehe. So re-frame frontend, a webgl visualiser that almost works and a whole lot of overkill graphql on the backend just because, haha. https://drive.google.com/file/d/1ICLmMudhQwt9okfFbFSDjyNecNfnIb1K/view?usp=drivesdk
But I do have a nice sort of idea of how to bring together editor clj, cljs snippets, GLSL shaders and afterglow params for a nice live coding workflow. We’ll see...
WOW, that’s awesome! :fireworks: Have you published this fork? I would like to link to it from my documentation! Should we think about merging your interface into Afterglow, or would you rather keep it as a separate project? Have you ever thought about building a UI to help people with fixture definitions? That is probably the steepest learning curve today.
You took your WebGL a lot further than mine! I got hung up on how much CPU my ray tracing was devouring, and had other projects take over my life. :)
Will def contribute but yeah things take time hehe. This project is I mean, it’s using my “tolglow” afterglow addons as a dep, so quite far removed. Im still very much in learning mode, not at all making anything easy for myself or taking shortcuts. Main thing is untangling general show control from the current mix of controller and web stuff.
I have some contributions for afterglow proper I could push whenever tho - switched out the color lib to a much faster thi.ng one, defrecord for params and gotten rid of all reflection = massive speedup
Not that performance is probably a big problem unless doing the whole led thing hehe. Anyways I’m further and further down the whole interceptor philosophy rabbit hole so holding off a bit on further touches to or revamping of afterglow proper til I have a better idea of how to get something like that going - basically reactive params :) and yeah more ui for sure, something for the defs then another view for patching. rotation and that should be doable straight in gl really. I think having the visualiser will help a lot!
And yeah your visualiser is proper fucked haha! No raytracing here just regular spotlights + a custom shader for the cone geometry. Holds up quite well, and easy to throttle back like, can do anything from light+shadows down to just the cones.
Like even this webgl stuff is still part reagent/re-frame, but obviously the second you stop declaring and start invoking you lose the awesome auto atom stuff... so suddenly back to polling and core.async :| Anyways simple example interceptors would help as well is like, instead of the whole show thing and manually wrapping everything with current snapshot (which gets in the way of both casual exploration and deeper development), have it injected as needed. And opening up effects by not requiring an explicit per-frame gen-fn but also like “I want this state in four bars”.
Wow, lots of interesting explorations! The improved color library makes a great deal of sense, the one I am using is pretty haphazard. I would have to take a careful look at what you were proposing with your defrecord for params. Records reduce flexibility, and move you towards Java from Clojure, so the benefit would have to be worth the tradeoff. Eliminating reflection is something I have definitely considered exploring, once we are certain that the API is settled. But yes, it would definitely be needed if you want to use a lot of individual LED pixels, I was able to swamp things pretty effectively that way with a few thousand pixels.
However, if you want to create a new way to define effects, you need to realize that they are going to have to be able to translate whatever you do into a function that maps a metronome snapshot to DMX values. That’s fundamental to how Afterglow works; when it is building the DMX frame that is going to be sent out next, it needs to be able to ask each effect, “here is the snapshot at which this frame will be sent, what DMX values do you want to contribute?” To work outside that model, you would need to create a completely different DMX approach, and it wouldn’t be Afterglow in any sense.
Have you considered adding live effect graphs to your awesome re-frame UI, like I have running on the Ableton Push 2? I have been wanting to add those to the web UI. I also want to be able to overlay Pioneer CDJ waveforms on the metronome and effect curves, to make it easier to run shows alongside professional DJ gear, and my Beat Link Trigger project makes that possible. Having something more modern and organized than my jQuery proof-of-concept UI would be a wonderful starting pont for that.
And yeah I'm talking more like, know how a nil assigner is skipped, some other value (or simply not being polled every frame in the first place) can mean "use latest value" - we're already saving a bunch more data for the visualiser, and prob the whole resolve assignment thing can be made pure (first collect and store abstraction-level results per head, then calc and push entire buffer at once off that instead of individual aset and swaping to atom)
Basically what needs to be changed for visualiser to fully work (emulated strobes and all) should also improve performance and make the whole thing more functional and flexible, which is convenient. And for the other question yeah graphing/visualiser is def going in the web interface. Which is gonna turn out so incredibly heavy haha, but lots of stuff can be optimised eg sparse updates and css transitions for color-fn, graph could also do interpolation if got lots at once...
the usual suspect thi.ng has a nice graphing lib I intend to use. And a massive geometry one, and webgl, and... Tons of insane stuff. And like all cljc and barely any deps which is nice when classpath is approaching 500 :S