www.toplap.org

The idea of live code updates seems to be a very exciting prospect. A lot of my current work focuses upon the idea of local narrative embedded within the structure of a program, and the ability to modify a program on the fly through an editing window is a great idea.

The above project is centered upon audio presentation and performance, but visuals are making an appearance it seems.

Does anyone have any experience of this?

I'm busy trying to get the fluxus engine up and running just to see how well it works.

I don't think I'm too concerned with the presentation of actual code to an audience.

From a performative point of view, I'd be more interested in how one could alter the form and structure of a program without having to break out and recompile each time, so that there is a seamless action. A great possibility would be a main window presenting a working program, and then a kind of sandbox area where code is being tested and written ready for dumping to the main area.

I've not looked into it, but I wonder if processing could allow for a similar kind of (Applet) buffering where the display window is running some code and new code could be being written in the background and then a seamless swap, or cross fade could take place.

It would just be case of writing some software that deals with applets in this way, making use of the export function.

I'd highly recommend checking out Rhino, a fully-featured javascript engine for Java.  It provides automatic wrapping of any Java object and class, so theoretically you could write an entire processing applet (draw method and whatnot) using javascript at runtime.  Or just have parts of your program automated by giving Rhino access some type of agent object you create.

If you're unfamiliar with Java, integrating Rhino may not be a trivial task but there are a great wealth of tutorials and reference materials on the website for anyone interested in experimenting with it.

cello wrote on Jan 1^st, 2006, 7:15pm:


I've heard of rhino but not played with it yet, but thanks for the encouragement to do so.  

However It would be nice to be able to livecode with processing directly though, and according to my experiments so far, perfectly possible, using proxy objects, dynamic class loading and reflection.

I'm familiar with javascript/ecmascript and java, and have looked around the rhino documentation but don't yet understand  what you're proposing.  Could you clarify please, or otherwise point me at the right documentation?

I have proof of concept livecoding working with java, and I'm not sure how rhino would produce an easier solution.

Thanks for that cello, very clear.

I don't think that's exactly what I want to do although I can't speak for others.  It's certainly interesting though with a lot of possibilities.

I'm not really thinking about users but myself  I want to load the processing editor, type in some code, press the run button and have the program start running.  Well this is how processing works already.  But then I want to change the code,  press the run button again, and have the program continue running with all its data intact, but with the new code.

That is, change code while it is running.  This is useful during development, you can make small changes and see results immediately.  It's also useful during performances, you can change the code of a VJ or music generating app to make wide ranging changes to the rendering output without having to make and be stuck within a restrictive GUI, and without any breaks in the output.

I've been livecoding with Perl for a couple of years now, it's a really great way to make stuff and perform it.

As far as I can tell there's no way to replace the code of a java class with a newly compiled one, and still have all the field values intact.  This is possible in many scripting languages but not Java.  So instead I'm proposing to hide the object behind a proxy object and do some smoke and mirrors to replace the object with one instantiated from a newly compiled and loaded class.

Anyway, I should release my proof of concept.  I'll finish it off and upload it somewhere hopefully by next weekend.

yaxu wrote on Jan 7^th, 2006, 8:53pm:


This is what we used to do at the Atelier Hypermedia before we switched from Lingo to Processing. It's one of the (rare) things that I miss from that world. We've been livecoding in the atelier for years, in fact many of the classes were built around modifying code while it runs. Processing has made everything else easier, but we lost livecode, which was really our dada...

When I first moved over to Processing I did try running several Processing instances at once on Windows (couldn't get it to work on my Macs, although it's possible with native apps). This was a wonky but fun way to recreate some of the livecode performances I've done in the past, and since I used Midi to generate the sound output, the audio/visual improvisation worked pretty good! I was even able to play around with a double-screen configuration to approximate some livecoding where you don't want the code on the same screen as the display (although I recommend always having the code visible in some form or another, otherwise it's just a video

yaxu wrote on Jan 7^th, 2006, 8:53pm:


This sounds promising! I agree that programming in Java/Processing syntax is better than using yet-another language (I'm guessing that I'm up to about a dozen, maybe double that, it's getting out of hand!) So sticking to Processing would be great, although Cello seems to suggest that you could run live Java code through Rhino, or maybe I didn't understand...

I've seen Alex perform, quite brilliant. Can't wait...

You may take a look at http://www.beanshell.org/ for an
alternative to Rhino.