# Visor - New tool for using Processing in live performance
**URL:** https://discourse.processing.org/t/visor-new-tool-for-using-processing-in-live-performance/8611
**Category:** Gallery
**Created:** [February 22, 2019, 12:01am UTC](https://discourse.processing.org/t/visor-new-tool-for-using-processing-in-live-performance/8611 "2019-02-22T00:01:30Z")
**Posts on this page:** 8
**Page:** 2
### Author:  [@neilcsmith](https://discourse.processing.org/u/neilcsmith)
#### Post date: [February 27, 2019, 10:25am UTC](https://discourse.processing.org/t/visor-new-tool-for-using-processing-in-live-performance/8611/21 "2019-02-27T10:25:21Z")
> [@jackvpurvis](#):
>
> The concept you defined here sounds interesting and I would like to read more.
[Just-in-Time Programming](https://www.praxislive.org/blog/just-in-time-programming/) š
> [@jackvpurvis](#):
>
> 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. ā¦ If I remember clearly, you cleanly separate your data from your sketch classes so the sketch code
This sounds familiar, apart from the showing deleted variables bit?! Properties, ports, triggers, etc. in PraxisLIVE are all instance fields, although you have to explicitly annotate those you want to be exposed / state maintained. So state is not separated from the āsketchā code as far as the _user_ is concerned - you interact with the instance fields as you would normally, and those fields provide a data schema. But on external messaging, code change or project load / save, the CodeContext that wraps the userās code handles injecting / reading values. Because each iteration of code is a new class with no retained state by default we can make a clear picture of the āworldā from one iteration to the next, handle transfer or disposal of state and resources automatically, and do almost all of that asynchronously. Basically this is about turning a major limitation of Java into an asset! š
> [@monkstone](#):
>
> Unfortunately `self` is not the processing app so I get this error
š¤£ now thereās a whole series of support queries Iām familiar with!
---
### Author:  [@jackvpurvis](https://discourse.processing.org/u/jackvpurvis)
#### Post date: [February 27, 2019, 10:37pm UTC](https://discourse.processing.org/t/visor-new-tool-for-using-processing-in-live-performance/8611/22 "2019-02-27T22:37:43Z")
> [@monkstone](#):
>
> Unfortunately `self` is not the processing app so I get this error
Try using `sketch` to access the underlying PApplet object! Let me know how you go.
> [@monkstone](#):
>
> 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:-
This is really exciting to see! Thank you for experimenting with that. I want to better facilitate inclusion of gems / Processing libraries in future - whether through a GUI (like Processing IDE) or simple API calls / path configurations.
> [@neilcsmith](#):
>
> This sounds familiar, apart from the showing deleted variables bit?!
Yeah since the code isnāt tied to the state like in Praxis, removing the code to create a variable (e.g: `@var_name = 123`) and executing it again wonāt remove the created variable. So instead you rely on the GUI to keep track of what state is currently present in your program and manage things (like deleting variables). Though you could also write code to delete a variable (e.g: `remove_instance_variable(:var_name)`)
> [@neilcsmith](#):
>
> Because each iteration of code is a new class with no retained state by default we can make a clear picture of the āworldā from one iteration to the next, handle transfer or disposal of state and resources automatically, and do almost all of that asynchronously. Basically this is about turning a major limitation of Java into an asset! š
This makes sense! It sounds very clean and it gives you a very clear picture about the state of the program / system. The only thing that getās me about this model in Java is the amount of boiler plate required to set things up! Do you often find yourself live coding properties, ports, etc?
---
### Author:  [@neilcsmith](https://discourse.processing.org/u/neilcsmith)
#### Post date: [February 27, 2019, 10:54pm UTC](https://discourse.processing.org/t/visor-new-tool-for-using-processing-in-live-performance/8611/23 "2019-02-27T22:54:53Z")
> [@jackvpurvis](#):
>
> The only thing that getās me about this model in Java is the amount of boiler plate required to set things up!
Yes, thereās a bit! Although it could be trimmed down _a lot_ from what currently exists in PraxisLIVE due to how itās evolved over time.
> [@jackvpurvis](#):
>
> Do you often find yourself live coding properties, ports, etc?
In performance, rarely. In live programming to build projects, teaching, talks, etc. all the time. Bear in mind it was built originally as a live development environment for building interactive projections and tools more than a performance tool. Stuff like [this](https://youtu.be/9D3cJDRF6Do) (from back when it was libGDX based rather than Processing). I was quite late to actually live coding as performance.
---
### Author:  [@monkstone](https://discourse.processing.org/u/monkstone)
#### Post date: [February 28, 2019, 10:45am UTC](https://discourse.processing.org/t/visor-new-tool-for-using-processing-in-live-performance/8611/24 "2019-02-28T10:45:48Z")
> Try using `sketch` to access the underlying PApplet object! Let me know how you go.
This worked after a fashion for arcball, but context was wrong:-
In JRubyArt, propane etc (and vanilla processing) the Applet instance is used to initialise many libraries methods that use java reflection to access :pre, :draw, :mouse\_pressed etc typically in setup so they pick up sketch context (size, render\_mode etc). But like in the case of arcball they might do a `translate` as well.
Unfortunately the above arcball sketch renders somewhat oddly instead having a box to rotate with an arcball I get box image on flat surface, which does apparently rotate (mouse\_dragged) and zoom (mousewheel)
---
### Author:  [@neilcsmith](https://discourse.processing.org/u/neilcsmith)
#### Post date: [February 28, 2019, 6:08pm UTC](https://discourse.processing.org/t/visor-new-tool-for-using-processing-in-live-performance/8611/25 "2019-02-28T18:08:51Z")
> [@monkstone](#):
>
> Unfortunately the above arcball sketch renders somewhat oddly instead having a box to rotate with an arcball I get box image on flat surface, which does apparently rotate (mouse\_dragged) and zoom (mousewheel)
Judging from that image, Iām assuming the layers in Visor are implemented as `PGraphics` so the `ArcBall` probably needs initialising with both the parent sketch and the graphics. At least, thatās my guess from seeing similar visual glitches with PeasyCam. I assume ArcBall can do this too?
---
### Author:  [@JackLaidlaw](https://discourse.processing.org/u/JackLaidlaw)
#### Post date: [February 28, 2019, 8:59pm UTC](https://discourse.processing.org/t/visor-new-tool-for-using-processing-in-live-performance/8611/26 "2019-02-28T20:59:47Z")
This looks very exciting. Iāll be digging into this over the Spring/Summer and showing it to my Audiovisual Technology and Sound & Music Technology students ASAP.
---
### Author:  [@jackvpurvis](https://discourse.processing.org/u/jackvpurvis)
#### Post date: [February 28, 2019, 11:29pm UTC](https://discourse.processing.org/t/visor-new-tool-for-using-processing-in-live-performance/8611/27 "2019-02-28T23:29:57Z")
> [@neilcsmith](#):
>
> Yes, thereās a bit! Although it could be trimmed down _a lot_ from what currently exists in PraxisLIVE due to how itās evolved over time. ā¦ I was quite late to actually live coding as performance.
Keen to see what that might look like! Also makes sense it was focused for building interactive tools.
> [@monkstone](#):
>
> This worked after a fashion for arcball, but context was wrong:-
Yeah so the use of translate on the sketch is problematic as there is a number of things going on underneath due to how layers are setupā¦ and @neilcsmith is correct: Layers are implemented with PGraphics under the hood. You can access a layerās PGraphics object using `graphics`, hopefully you can initialise using that instead. Let me know how you go, itās possible this side of things still needs work to ensure it works with Processing libraries in the correct manner.
---
### Author:  [@monkstone](https://discourse.processing.org/u/monkstone)
#### Post date: [March 1, 2019, 3:34pm UTC](https://discourse.processing.org/t/visor-new-tool-for-using-processing-in-live-performance/8611/28 "2019-03-01T15:34:12Z")
With latest knowledge re `graphics` I have managed to extend the functionality provided by my [vecmath](https://ruby-processing.github.io/vecmath/) gem see link. Iām not too bothered about lack of ArcBall functionality as I was only using it as easy example. The challenges may come if I try and use one the other ruby-processing gems, such as `toxiclibs` and `jbox2d` gems.
[Previous page](https://discourse.processing.org/t/visor-new-tool-for-using-processing-in-live-performance/8611.md?page=1)