Visor - New tool for using Processing in live performance

[jackvpurvis]

@monkstone

I am very impressed with sonic-pi that seem to combine the possibility of a teaching/learning environment (instant feedback to user) with a tool that can be used for live performances. But I guess its not that simple for video.

Sonic Pi is fantastic in that you can condense musical actions into simple lines of code, e.g: play :e2 or sample :amen. It seems it is harder with video as there are more dimensions at play, making it harder to express simply. We could focus more on samples (like music) with video clips (like VJs) but then we lose the flexibility of generative graphics. I’m interested into how we can build environments to allow us to work at a high level (VJing) and at a low level (creative coding generative graphics).

@monkstone

I don’t know how Joshua Davis works his code on stage but I’ve translated a number of his Hype_Processing examples for JRubyArt.

I could be wrong but I think Joshua uses pre-written sketches where parameters are mapped to MIDI controllers to allow for interaction during performance. Visor offers features to more easily create these kinds of mappings, even during a live performance.

@neilcsmith

Wrote something recently where I called it transactional code changes. But thinking of systems where the code at any point in time reflects the whole state of the system at that time. ie. You don’t have to replay the entire history to replicate the current state, if a resource is removed from the state it is as if it never existed, etc. More declarative less imperative.

I have a feeling you may also have addressed some of that in the framework you have?

The concept you defined here sounds interesting and I would like to read more. I also agree that it is useful to have the code fully represent the state of the system. I couldn’t think of a straight-forward way to do this with Processing in Ruby and also achieve the amount of liveness I was looking for, so I opted to use reflective techniques to visualise the state of the system. For example, the state GUI shows you all of the instance variables that are currently defined on the layer, even if you deleted the code to create a variable. What Visor lacks currently is a way of presenting what methods or classes are currently defined. So there is definitely a disconnect between the code and the system state, but it allows you to work more imperatively with the REPL-like code editors.

How does PraxisLIVE go about this problem? If I remember clearly, you cleanly separate your data from your sketch classes so the sketch code can be completely hot-swapped without affecting the state of the data?