These are chat archives for brunchboy/afterglow

1st
Sep 2018
Joen Tolgraven
@tolgraven
Sep 01 2018 15:52
reckon?

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

Joen Tolgraven
@tolgraven
Sep 01 2018 16:56
anyways apart from the general direction that way pitch I have some ???.
  1. 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... did map bang your mom halfway into writing afterglow, or something?
  2. 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?
  3. 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 :)
James Elliott
@brunchboy
Sep 01 2018 21:27
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.
Joen Tolgraven
@tolgraven
Sep 01 2018 21:33
Oh fair play just figured from how clean a lot of the core is you knew your stuff from before. Makes sense then! Even more impressed now haha. I guess my real point was I think a fair amount of the code (especially outwards facing) should be changed and boiled down.
James Elliott
@brunchboy
Sep 01 2018 21:33
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.)
James Elliott
@brunchboy
Sep 01 2018 21:41
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.)
Joen Tolgraven
@tolgraven
Sep 01 2018 21:44
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