Field & Quil [was: Field & Processing]

[Marc Downie]

I'll heartily agree about Clojure; and Nick has the indisputable advantage of not being me when it comes to advice about Field and things that aren't Field. 

I will add, though, that in most recent builds of Field and Quil the following will work:

(use 'quil.core)
(use 'quil.dynamics)
(use 'quil.applet)

(.set applet-tl user/p)

(defn get-field-var [q]
    (.getVariable (field.core.execution.PythonInterface/getPythonInterface) q))

(defn _r []
    (stroke (random 255))
    (stroke-weight (random 10)) 
    (fill (random 255)) 
    (let [diam (random 100) 
        x (random (* (get-field-var "_t") (width))) 
        y (random (height))]     

        (ellipse x y diam diam))

)

This gets you a Processing applet with random circles, the distribution of which is controlled by _t.

The magic incantation here is "(.set applet-tl user/p)" which hacks Field's embedded dynamic Processing applet into the heart of Quil — the exact phrasing of this has been changing with new versions of Quil I'm afraid, but it seems like it has stabilized now. 

This seems to my eye to be strictly more fun that Quil+Emacs — I don't see any built-in architecture for incrementally composing a draw-fn on the fly without tearing down and reinitializing your applet in straight Quil. It doesn't seem to have a real "live-coding" feel about it. Of course, I've spent all of an hour with Quil, so it's likely I'm missing something.

While I've have seen no threading krankiness between Field and Processing 1.5x for a while, the move to Processing 2.0 has thrown everything up in the air again.

best,

Marc.


On Tue, May 1, 2012 at 5:07 PM, nick rothwell <ni...@cassiel.com> wrote:
>
> If you want to stay close to Processing but use a language that's somewhat more modern and flexible than Java, you could look at Quil, which is the Processing back-end with Clojure as the front end. It allows live coding by spawning a Clojure service while running the sketch, but for best results you'll really have to be comfortable with Emacs:
>
> https://github.com/quil/quil/
>
> If you want to use Field (for the graphical workspace, or for the time slider machinery, say) then you can run Clojure here as well. Bridging to Processing is a little kranky in my experience, so for basic graphics (from either Clojure or Python) I suggest the PLine/FLine machinery:
>
> http://openendedgroup.com/field/wiki/FLineReference
>
>
> --
> You received this message because you are subscribed to the Google Groups "Field-development" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/field-development/-/iUKoFYtdxN0J.
>
> To post to this group, send email to field-de...@googlegroups.com.
> To unsubscribe from this group, send email to field-developm...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/field-development?hl=en.

[nick rothwell]

On Wednesday, May 2, 2012 3:35:12 AM UTC+1, Marc Downie wrote:

This seems to my eye to be strictly more fun that Quil+Emacs — I don't see any built-in architecture for incrementally composing a draw-fn on the fly without tearing down and reinitializing your applet in straight Quil.

I'll readily admit that I've spent even less time in Quil than you have (despite the fact that I have to give a presentation on it at EuroClojure in a couple of weeks), but I'd fully expect that you'd be able to dynamically rebind functions in namespaces (or to be even more dynamic, use the #'varname trick employed by Overtone).

One thing I want to try soon is hosting Clojure in Field (which I've already used for several projects) but opening a network server so that the Clojure code can be edited and live-patched from Emacs. (I've been using Emacs for about ten times as many years as I've been using Field, and for putting together larger codebases in languages like Python and Clojure it's my favourite environment.)