Field & Processing

[yade]

Hi,

First of all sorry for my bad English ... i'll try to do my best.

I just discovered Field, it looks awesome. Congratulations for your great job !



I used VVVV for years, and I liked his philosophy.

I'm learning right now Processing, which corresponds rather well to what I want to do
(graphics & motion-graphics rendered in PDF or. MOV... 
OSX, Windows, iOS or Android applications...  
web with Processing.js  ...).



But I would have a much more intuitive use of Processing (in some ways, I prefere VVVV) :

- I would have the ability to live-coding (seeing the results in real-time live when i'm coding. It seems Field is exactly what I search)

- Most importantly, I 'd like to work with a nodal interface with Processing code that I use regularly... (using the Field's boxes? )




Here's a little diagram that explains better what I'd like to do :

Is Field a good choice for this use ? (using Processing in "nodal mode" ?)

Is Field would not be too complex for such use? (needs to know basic Python ?)




Thanks !

y

[Joseph Gray]

Maybe try purdata or max/msp?

y

--
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/-/CjTHbQSeo-sJ.
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.

[Marc Downie]

Yade,

While it's true that you could build something that looked very close to your diagram in Field (short form you'd use http://openendedgroup.com/field/wiki/TopologyAndControlFlow for the UI and then a little bit of python to scan over the tree's you make to assemble the actual logic) I'm really not convinced it would be worth it. I think the granularity — having "100" and "x" each have it's own box — is just too fine and things are going to get out of hand fast. VVVV / pd / max/msp/jitter seem like something that are are more aligned with your style.

That all said, I'd be interested in hearing what it is that you feel that Processing is giving you that VVVV isn't, and perhaps we can come up together with some nodal hybrid system that plays to Field's strengths more.

best,

Marc.

y

[nick rothwell]

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

[yade]

Hi,

thanks for your answers !



For me, here are the Processing advantages  :

- export in one click in :
. OSX App
. Windows App
. Android App
. iOS App
. HTML 5

- available on OSX, Win & Linux

- lots of documentation (and a lot in french)

- lots of library



VVVV advantages :

- real time coding

- very efficiant nodal interface (far more efficiant than pd or max)

But Windows only, and no export at all (patchs work only on your own computer).




I think I found what I searched : it could be Nodebox Scene Builder.

Badly, It looks like development seems to have stopped...


y

[Marc Downie]

On Thu, May 3, 2012 at 4:21 PM, yade <yann....@gmail.com> wrote:

Hi,

thanks for your answers !

For me, here are the Processing advantages  :

- export in one click in :
. OSX App
. Windows App
. Android App
. iOS App
. HTML 5

These are undeniable advantages to Processing. And I should remind everyone that they are not getting one click "export" from Field/Processing. Processing's export to Java Applet feature is actually disintegrating as performant, stable, predictable Java-in-the-web-browser becomes increasingly hard to find (everybody is betting on Processing.js).

[snip]

I think I found what I searched : it could be Nodebox Scene Builder.

That looks like it was based off of Nodebox1 which was profoundly Mac Desktop only — it was a Python / CoreGraphics thing. Nodebox2 is pretty interesting (and much more like Field under the hood — Jython/Java). Field can hack it's way into Nodebox2 without much trouble if you fall in love with their geometry libraries and documentation, and either way it's worth a look. 

But of course, even if it did export to an Applet, it would suffer from the same problem as classic Processing in the web-browser.

 

best of luck in your search,

Marc.

Badly, It looks like development seems to have stopped...


y



Le mercredi 2 mai 2012 00:07:31 UTC+2, nick rothwell a écrit :

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/-/8Z_gHhhBB_oJ.