livecoding with Quil middleware

[Jay Porcasi]

hello, i hope this is the place to discuss questions about Quil (i couldn't find a dedicated forum)

and first of all, kudos to Nikita for this incredible library, which i find even better than the original Processing

it's not just a matter of using a different syntax than java, but Nikita actually created something more powerful and flexible than Processing

i'm particularly fond of the middleware functionality, which is a stroke of genius: so simple in retrospect and so powerful, opening a whole new way of possibilities of structuring one's own work in a modular fashion

so i have one question regarding live coding and middleware

if i redefine a function that i associate to :setup, :update or :draw keys, i can see my running sketch changing on the fly, reflecting the new definitions

this is not the case however if i redefine a function that i use as a middleware

is it an intrinsic limitation? would it be possible to extend the live coding behaviour to middlewares as well?

thanks and long live Quil,

Jay

[Nikita Beloglazov]

Hi Jay

Yes, draw and update functions support live coding out-of-box. It's trickier with middleware. The main thing is that middleware run once, when initializing sketch. The goal of middleware is to take user provided settings (like draw and update funcitons), optionally wrap some of them in another functions and return new settings. It depends on your middleware implementation whether it supports live coding. As a simple example let's say you have a simple middleware that fills background with some color before each draw. Here is how you can do it so it supports live reloading:

(defn fill-background [draw-fn]

  (q/background 255)

  (draw-fn))

(defn fill-background-middleware [options]

  (let [user-draw (:draw options)]

    (assoc options

      :draw #(fill-background user-draw))))

(q/defsketch abc

  :draw ...

  :middleware [fill-background-middleware])

If you try changing 'fill-background', for example change color from 255 to 200, then you should see effect immediately. The trick is on line 

:draw #(fill-background user-draw))))

Here we say that new draw function is an anonymous function that calls fill-background. So on each draw invocation it will lookup fill-background function by name. If you reload this function - name will stay the same, but implementation changes and interpreter pick ups new function. On the other hand if you do following:

:draw (partial fill-background user-draw)

Then you won't get live reloading. Even though these 2 approaches essentially do the same, the second approach actually "remembers" original version of fill-background. If you try changing that function it won't have effect as interpreter no longer looks up function by name. 

I'm probably not explaining it very well but I hope it's still helpful. If you still have problems with your middleware - feel free to post the code in this thread and I'll take a look.

Nikita

[Jay Porcasi]

hi Nikita

thank you so much for your explanation, it's very clear (and a bit surprising to learn that partial and anonymous functions have a slightly different semantics)

i am able to get the live coding behaviour when i redefine fill-background (as per your example, and that's great that it is possible)

however it seems not possible to get a live coding behaviour when redefining fill-background-middleware (the middleware function itself)

for example i would love if i could evaluate:

(def fill-background-middleware identity)

and see the background reverting to what it was before (that's just an example)

but this seems not possible because that middleware runs just once, when the sketch is initialized

do i understand correctly?

and is it something that would not be achievable by any other means? (one more level of indirection perhaps? :-)

Jay

[Nikita Beloglazov]

Yes, middleware runs exactly once so you can't redefine it. In the example with fill-background you can redefine fill-backgfound:

 (def fill-background [draw-fn] (draw-fn))

Which essentially makes it identify. So that's would be my recommendation: put all logic to fill-background and let fill-background-middleware be just a wrapper like it is now. 

[Jay Porcasi]

thank you very much Nikita

by playing with anonymous functions vs partial applications i got exactly the behaviour i was after!

that's awesome :-)

Jay