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!
now there’s a whole series of support queries I’m familiar with!
Try using sketch to access the underlying PApplet object! Let me know how you go.
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.
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))
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?
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.
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 (from back when it was libGDX based rather than Processing). I was quite late to actually live coding as performance.
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)
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?
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.
Keen to see what that might look like! Also makes sense it was focused for building interactive tools.
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.
With latest knowledge re graphics I have managed to extend the functionality provided by my 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.
now there’s a whole series of support queries I’m familiar with!