I’m excited to share a new tool that I’ve been developing called Visor that allows for live coding of Processing in the Ruby language. Visor attempts to empower Processing for live performance by combining elements from live coding and VJing practice. Visor offers user interfaces to easily interact with live coded sketches, aiming to make it as easy as possible to perform with creative code. Here are some of the core features of Visor:
Live coding with Processing - Update your sketch in real-time without restarting the application.
Ruby language - Simple creative coding while making use of powerful language features such as enumerators and blocks.
State interface - Interact with sketch parameters as they are automatically displayed in the interface.
Layers - Organise your code into rearrangeable layers and configure their properties to create new compositions.
Audio analysis - Inspect the audio frequency spectrum and access the audio data in the code to drive visuals.
Tap tempo - Tap to the tempo of the music and create visuals that animate on the beat.
MIDI support - Configure MIDI controllers to create mappings between controls and sketch parameters.
Learn hub - In-app documentation to help you get started or dive deeper.
You can learn more about Visor, watch demonstration videos, and download it from the website here: www.visor.live
Visor wouldn’t be possible without Processing, JRuby, Electron and a number of other important libraries such as minim and themidibus - so a big thanks to everyone who’s contributed to these projects.
If you have any feedback or questions, please fire away, I am eager to hear what you have to say. Please note that Visor is still in an alpha stage. Thanks in advance to anyone who gives it a try!
Hi @jeremydouglass, thank you for your reply! You are correct - currently the project is closed-source while I develop it as part of my masters research but I intend to open-source it in the future
Hey @neilcsmith, personal choice - I’m new to open source and have yet to work out how I should set it up, my focus has been on finishing up the research side of things. I’d be keen to hear your input about the topic as I’m sure you’ve worked through it with PraxisLIVE. I’ll flick you a message!
Hey @monkstone, nice to meet you - I did come across your projects early on and was certainly inspired by JRubyArt. I think it’d be worth chatting at some point as there will be some learnings in how we have approached using JRuby and Processing together.
I am certain there are great possibilities for sharing experiences. For my part the closest thing I have come to using in electron is indirectly via my atom packages:- atom-k9 to run / watch sketches from atom language-jruby-art code snippets
But you may well be interested in my more ruby like replacements for PVector:- Vec2D Vec3D
And library loader functionality, not to mention a large number of ruby example sketches, including those using processing libraries and custom gem wrapped libraries toxiclibs, geomerative etc.
Fair enough! Makes sense, and glad it’s by your choice. At the same time, I’m keen to have a play, and also have a look underneath at how you’re solving certain problems, but try not to run non-FLOSS stuff on my system whenever possible.
Got your message, and will respond there, but what I will say here is that it’s a continual work in progress! And I think that’s true of every FLOSS project I’ve worked with.
I had a chance to give Visor a go, and in my hands does not feel any more like live coding than JRubyArt in watch mode run from atom. For something that looks more like live coding to me see MoiRouhs
I think you probably need to delve a bit deeper! But I’m intrigued what about that link you consider to be more live coding? It’s hard to tell exactly what’s going on.
Pry is more sophisticated version of the vanilla ruby irb (repl tool) that allows you to inspect, and modify code on the fly. For JRubyArt you can start up pry on your sketch as follows
k9 --live my_sketch.rb
The @MoiRouhs example is slightly confusing in that the text is overlaying the sketch. Having the sketch display in a regular window is more normal. Class wrapped sketches work better than ‘bare sketches’ (that get wrapped in class anyway before they are run).
That’s fairly normal in live coding (as performance as distinct from interactive / live programming). What I can’t tell is whether you have glitch free code updates with state retention in that link - it’s really difficult to make much out, hence the question. I’m also not clear why you consider that more live-coding? This might be interesting reading on Visor btw - 747Live Casino - Where Every Game is a New Adventure
REPLs are useful tools, but I’m also somewhat sceptical about most of them for live coding, or even interactive programming. That’s going rather off-topic though - possibly another thread on general “liveness” split off from this would be an interesting discussion? @jackvpurvis am I right in remembering that the REPL section in the paper got changed in Visor?
Extending atom is really powerful and a number of live coding environments do this (e.g: atom-hydra). With Visor I opted to create the GUI from scratch to have more control. Trade-offs both ways I’m sure.
These are really fantastic!!
What is it about class wrapped sketches that make them better than bare ones?
While I haven’t live coded with Pry, I believe Visor works pretty much the same (but more constrained) as the lines of code are automatically instance eval’d on persistent layer objects (you can pretty much think of each layer as a sketch, each has it’s own state and draw method). This guarantees state retention for seamless live coding performances. Does the Pry method preserve state?
I’m interested as to why you are skeptical about REPLs in live coding! I would be keen to create another thread for the liveness discussion. And yes, Visor has since evolved to merge the REPL and Draw editors together. So instead of having your draw code in a seperate editor you just wrap it in a def draw. All the code is evaluated against the same layer object anyway so it made sense to combine the two. Regardless, the editor is still acting like a REPL.
Thanks for that clarification, as @neilcsmith said I probably needed to delve a bit deeper, I suppose my expectations interests are bit different (I’m not too bothered about live performance). 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.
Regarding class wrapped sketches working better, it may be peculiar to pry but is easier to address methods for editing:-
edit -p MySketch#draw
pry is supposed to preserve state. 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.
Hiii @monkstone, I try to use Jruby_Art for livecoding performance, but at this moment to do livecoding with it is very complicated. I work with Jruby_Art because I find your tool great for me (I love ruby and vim), when you spoke about sonic pi, I thought that you had a similar purpose with jruby_Art, I want to know if in the future Jruby_Art will have this possibility.
I know a huge amount of work went into Sonic-Pi, and I don’t think I’m up to it, may’be Visor is interesting to you. kn1kn1 did something with ruby-processing and sonic-pi, but it seemed more like using sonic-pi as editor for ruby-processing albeit using the sonic-pi interface.
Depends partly how we define REPL. And I don’t think it’s a black and white distinction. I also misspoke - meant it’s more of an issue in interactive / live programming, where it’s about having a replicable state for an end goal. 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?
Having written a tool for both, I’d say video is simpler. Music / audio tends to have more temporal concerns to handle - don’t tend to work with discrete frames in quite the same way.
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).
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.
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?
I thought I would be a bit clever and try to use my arcball gem in a sketch.
GEM_HOME = '/home/tux/.gem/ruby/2.6.0'
require 'arcball'
Processing::ArcBall.init(self)
def draw
clear
end
Unfortunately self is not the processing app so I get this error
Visor$$Layer_627236044 cannot be cast to processing.core.PApplet
However it filled me with optimism that I could use my gems with Visor, and in the first instance I created a custom gem to provide Vec2D and Vec3D to the Visor environment.
See result:-
And I think that’s true of every FLOSS project I’ve worked with.
But I’m intrigued what about that link you consider to be more live coding? It’s hard to tell exactly what’s going on.
I’m also not clear why you consider that more live-coding? This might be interesting reading on Visor btw - 
And I don’t think it’s a black and white distinction. I also misspoke - meant it’s more of an issue in interactive / live programming, where it’s about having a replicable state for an end goal. 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.