Re: livecoding with Quil middleware
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 On Friday, March 24, 2017 at 7:00:41 AM UTC+7, Nikita Beloglazov wrote: > > 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. > > On Wednesday, March 22, 2017 at 8:22:59 PM UTC-7, Jay Porcasi wrote: >> >> 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 >> >> >> >> On Monday, March 20, 2017 at 11:09:35 AM UTC+7, Nikita Beloglazov wrote: >>> >>> 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 >>> >>> On Friday, March 17, 2017 at 7:50:02 PM UTC-7, Jay Porcasi wrote: 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?
Re: livecoding with Quil middleware
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. On Wednesday, March 22, 2017 at 8:22:59 PM UTC-7, Jay Porcasi wrote: > > 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 > > > > On Monday, March 20, 2017 at 11:09:35 AM UTC+7, Nikita Beloglazov wrote: >> >> 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 >> >> On Friday, March 17, 2017 at 7:50:02 PM UTC-7, Jay Porcasi wrote: >>> >>> 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 >>> >>> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to
Re: livecoding with Quil middleware
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 On Monday, March 20, 2017 at 11:09:35 AM UTC+7, Nikita Beloglazov wrote: > > 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 > > On Friday, March 17, 2017 at 7:50:02 PM UTC-7, Jay Porcasi wrote: >> >> 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 >> >> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: livecoding with Quil middleware
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 On Friday, March 17, 2017 at 7:50:02 PM UTC-7, Jay Porcasi wrote: > > 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 > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
livecoding with Quil middleware
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 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
