A live-coding lighting controller, building on the Open Lighting Architecture with Clojure and bits of Overtone.
Haven't gotten on it yet hehe. Started trying to figure out how to create a virtual port from clojure using coremidi4j but it's a bit over my head :/ but also realised probably nothing needs to be done to wayang actually, would be cleaner to keep the handle open I guess but bottleneck afa connecting to push isn't in wayang, but in the afterglow auto midi port scan.
My chops are developing at a decent pace at least, cleaning up much of the repeated code from examples.clj so have for example a general make-osc-dimmer-cue instead of separate ones, and other stuff like that to make everything less configy/scriptish, has been doing wonders for my clojure skills :)
That’s really interesting, @joedemax, I will have to see if their JSON format offers any more useful information than the QLC+ format they offer, and if so, write an importer for it. (I can already import QLC+ format files.) People will almost certainly still need to add Afterglow-specific things like the formulae to figure out exactly where in space the head rotates for particular DMX values, but it is always nice to have a starting point.
hi! @brunchboy asked me what i'm doing with afterglow, and linked me here. currently i'm just experimenting and learning, but i plan on doing lightshows for a small band (and maybe some electronic acts too) with it. currently i use QLC+, before that i used dmxcontrol, but i always had this idea of writing a live coding lighting controller, i had experimented with some simple effects using python and the ola api. at some point i stumbled across this project and thought, wow, thats exactly what i was looking for. but i have no background in clojure, so i'm currently learning that aswell, maybe i'll be able to contribute in the future.
Thanks @NHGmaniac and welcome! I’m happy to answer any questions you might run into, and am glad to have a reason to poke around a bit in afterglow again. I have been pulled into side projects like Beat Link Trigger for a while (although I am not complaining because that got me put on the guest list for the Ever After music festival near Toronto this coming weekend, and backstage passes to meet some producers and artists who have been using it! :grinning: ) With any luck I may be able to interest someone in that space to experiment with afterglow as well.
Thanks for the welcome, @brunchboy ! Thats pretty cool, have fun at the festival :) I actually am currently stuck on a problem, that is i can't get spatial effects to work, i patched my fixtures with coordinates and tried the example hue-gradient effect, but all fixtures show the same color.
i'm sure its my fault, i just could not find my mistake yet :)
the show is in src/afterglow_pg/testshow.clj, and you'll have to adjust the dependencies in the project.clj as i've set afterglow to 0.2.5-SNAPSHOT (local build of the fix i pr'd)
i think i tried that before and it did not work, but i must've done some other small mistake back then :) so, next question: i tried making a simple effect that spreads a 'dimmer wave' over the the whole grid, line 170 in my showfile, inspired by the can-can chase in examples.clj, but i can't get that to work (all dimmers stay at 0)
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!