Processing 1.0 - Processing Discourse

FloHimself Ex Member	Re: LiveCode Reply #15 - Jan 15^th, 2006, 1:20am Livecoding with Processing http://rzserv2.fhnon.de/~lg016586/processing/processing_livecoding.avi

yaxu YaBB Newbies Offline Posts: 6	Re: LiveCode Reply #16 - Jan 15^th, 2006, 1:11pm nice! how is that done? hotswapping?

FloHimself

Re: LiveCode
Reply #17 - Jan 15^th, 2006, 2:36pm

this is done in a similar way cello mentioned,
but with the beanshell interpreter. i prefer
this one because of the real (strict or loose)
java syntax.

this is a very simple approach to livecoding and
could be done more elegant for sure.

Code:


import liveCode.*;

LiveCode lc = new LiveCode(this);

void setup(){
  lc.call(dataPath("livecode_setup.bsh"));
}

void draw(){
  lc.call(dataPath("livecode.bsh"));
}

i just wrapped the beanshell interpreter to a very simple
processing library, that gives you the possibility to call
beanshell scripts and export processing objects to
these scripts, and that hides all this imports and exception
handling stuff for cleaner sketches.

this is just a POC you may take a look at.
you can download the example and lib here:
http://rzserv2.fhnon.de/~lg016586/processing/liveCode/liveCode.zip

p.s.: sorry, no docs, readme, whatever yet... Tongue

cello

Re: LiveCode
Reply #18 - Jan 15^th, 2006, 6:50pm

Quite funny, I found out about beanshell on another forum for the first time yesterday. From what I read it sounds like a good alternative to Rhino (although it wasn't clear if it had a compiler or not, which gives Rhino the speed edge).

I'm curious how fast that runs, is it actually reading the file every frame? Does beanshell provide a means of loading the script file into an intermediate java object type, then you can execute that multiple times, presumably a little (a lot?) faster because you don't have to read the file and parse it 10s of times per second, theoretically thrashing the hard disk. Then you would have some 'update' button or something on your applet that tells it to reread the file.

Or if you integrate a text editor into the applet and just reload the script directly from the text area. You could open up a JFrame with a textarea or something, or if you really wanted to be sneaky, hack into the processing IDE and open up a mini processing IDE, that'd be quite sweet.

If you wanted to go a step further, you could detect syntax errors and keep running the previously working script until a newly working one is running.

An alternative step further than that would be to have a dual display as I think someone mentioned earlier. You have a 'test' display that shows the current script, then a 'published' display that shows the current published script, theoretically on a second monitor or even full screen on that monitor (using java 1.4's graphics devices support thing). Then when you're satisfied with your updated script, you click some other button that transfers it to the published display.

That would make it run slower, but you could probably work something out with using two computers and sending the change over a network, or simply run the test version at a super low framerate and let the published version take most of the CPU (or arguably, since Processing isn't multi-threaded, any multi-processor/core system would run two processing applets at the same speed as one).

(It's worth noting that the examples you have will work the same character for character in Rhino.)

Marcello

FloHimself

Re: LiveCode
Reply #19 - Jan 15^th, 2006, 7:16pm

i like beanshell for several reasons and it seams that
beanshell will find its way to the J2SE package some
day in the future.

you're right, it "reads" the file every frame. anyway it
is very fast and i think it is some kind of "cached" access,
because i can't notice heavy harddisk access.

very nice ideas! i would like to work on something like
that, but i think, i don't have time to do this alone.
exams are near and i have several projects to finish.
anyway, i like the idea of having the processing IDE as
livecoding tool. for syntax checking the beanshell parser
can be used.....

cello

Re: LiveCode
Reply #20 - Jan 15^th, 2006, 7:55pm

I'm not sure how your code works but if you define some variable in the shell, won't it reset it each frame? Do you have a means of providing 'global' data that persist from executing to execution? As far as I can tell, what you're doing is not much different from recompiling the class and restarting it from scratch. It's actually possible to do this with real Java (and you get all the benefits of a real java compiler and bytecode). You can use a dynamic class loader to reload class files on the fly without restarting the program. That's fine for calling methods, but I'm not sure how data persists, if at all.

FloHimself

Re: LiveCode
Reply #21 - Jan 15^th, 2006, 9:00pm

no, it won't loose the vars each frame. the "new" file will
be evaluated in the current interpreter context, that will
persist the whole time, until you stop the PDE. for example,
if you define a var in livecode_setup.bsh, you can use it
in livecode.bsh. also the interpreter context is
serializable. so it should be possible to "save" a session.
there could also some kind of "compiled" scripts, i read
somewhere. but i need to dig deaper in the beanshell docs.

btw, my first approach was calling a setup(); and draw();
defined in bsh each time. but it seems that beanshell
don't like the re-definition of methods each frame. it eats
more and more memory each re-define. so i used this very
simple way it is now, to avoid this.

for the mentioned heavy file reading, maybe a simple
sketch, that only reads the new file after a
right-mouse-click (or something like that on mac) would
be an solution.

i can't imagine all quirks that will raise up with the
current approach, but i think with this simple way
and some clever sketch, you could have some happy
livecoding.

FloHimself

Re: LiveCode
Reply #22 - Jan 16^th, 2006, 5:44pm

ok, i've updated the lib above. now it should be possible to access the processing methods in the scripts without the annoying "p." prefix. there are some more features, wrapping methods for the beanshell interpreter mostly, but still no documents... Sad

but the more i think about the livecoding thingie, the more i like the idea. maybe i will try to integrate a minimalistic editor for the scripting and maybe based on the current PDE.

the problem here is, i can't checkout the source from SVN, because i live behind an really angry proxy... and downloading the source from web-svn interface... well, i would get angry i guess...

we will see, if i can get some time to work on something...

cello Full Member Offline Posts: 143	Re: LiveCode Reply #23 - Jan 16^th, 2006, 7:28pm For documentation I recommend two things. Include the source for the library and write javadoc tags on all the methods. Then you can easily generate documentation from there, but even if you don't, people can just read the source.

FloHimself Ex Member	Re: LiveCode Reply #24 - Jan 16^th, 2006, 8:02pm sure, i will provide the source and will (maybe) do heavy commenting. i managed to get some svn client running. well, what i need now is much more time......

FloHimself

Re: LiveCode
Reply #25 - Jan 19^th, 2006, 10:55pm

Hi,

because my time is really limited at the moment and i found myself playing with the BeanShell Interpreter in my free time, rather then building a LiveCode library, I compiled a small demo with an simple wrapper class for the BeanShell. So no external library (except the beanshell itself of course) is needed for this example. This way everyone can take a look into this and see how easy the integration of a scripting engine into a processing project is or maybe someone just likes to play with something like this also: http://rzserv2.fhnon.de/~lg016586/processing/Processing_Interpreter_Demo.zip

However, i have really nice ideas for the live coding thing, and will experiment with it further when things calm down here.

Flo

jesusgollonet

Re: LiveCode
Reply #26 - Jan 20^th, 2006, 9:03am

Hi flo.

I've downloaded the source just to have a quick look and am not being able to make it work. I have the beanshell in the code folder and in fact that seems to work, as it throws some errors in the setup and draw files. It doesn't interpret any of them.

I just wanted to know whether i am doing something wrong or something is missing from the zip file.

I'm on win xp, processing 0102.

This is what the print throws.
Code:

Sourced file: inline evaluation of: ``importObject(p);'' : Command not found: importObject( Temporary_2137_7308 ) : at Line: 1 : in file: inline evaluation of: ``importObject(p);'' : importObject ( p ) 


Sourced file: C:\Documents and Settings\jesus\Mis documentos\Processing\inspiration_sources\livecoding\Demo\data\setup.bsh : Command not found: println( java.lang.String ) : at Line: 8 : in file: C:\Documents and Settings\jesus\Mis documentos\Processing\inspiration_sources\livecoding\Demo\data\setup.bsh : println ( "BeanShell is printing a String " + aString ) 


Processing is printing a String from Processing

Sourced file: C:\Documents and Settings\jesus\Mis documentos\Processing\inspiration_sources\livecoding\Demo\data\draw.bsh : Command not found: stroke( int ) : at Line: 1 : in file: C:\Documents and Settings\jesus\Mis documentos\Processing\inspiration_sources\livecoding\Demo\data\draw.bsh : stroke ( 255 )

all in all, really exciting. I've been wanting to try livecoding for a while, and doing it from within processing would be a lot easier for me.

Thanks a lot.

http://www.jesusgollonet.com/blog

FloHimself Ex Member	Re: LiveCode Reply #27 - Jan 20^th, 2006, 10:22am Hi jesusgollonet, can you please try to use this http://www.beanshell.org/bsh-2.0b4.jar instead of the one mentioned in the skretch source? It seems it needs more then the core interpreter to import objects into the root namespaces. If it works, please let me know and i update the notice in the source. Thanks, Flo

jesusgollonet

Re: LiveCode
Reply #28 - Jan 20^th, 2006, 12:18pm

yehaaa, it works.

...and it's great!

by now i've just drawn some random rectangles to try it, but it gives a great on-the-fly sensation.

I'm even thinking that it could be a good tool for processing beginners, as seeing your changes in realtime gives you a great feedback.

Thanks very much, flo. I'm sure i will give it a deeper shot some time soon.

http://www.jesusgollonet.com/blog

yaxu

Re: LiveCode
Reply #29 - Jan 20^th, 2006, 6:39pm

Nice work Flo, I'll have to try it out later. Maybe you could add it to the toplap systems wiki page: http://toplap.org/index.php/ToplapSystems

I got my java livecoding thing working, it is here:

http://yaxu.org/livework.tar.gz

Let me know if you get it working somehow (or otherwise). It's not plugged in to processing, but is a proof of concept of a way of livecoding with native java. I did it for coursework, so it has a lot, maybe too much documentation

cheers,

alex