More PatchBox musings
Finally got around to adding a few new features into PatchBox that I’m planning to utilise for the upcoming Belle Atmos gig on Wednesday:
- Ability to lock screens so they can’t be edited (useful when you’re dealing with more than about 10!)
- Fixed Z sorting so screens can be moved in front and behind others
- When dragging a texture onto a group you can now hold the shift key to duplicate the texture across all screens, rather than spreading it.
After the last gig a couple of months ago where I was using 25-30 screens with five live video streams (mostly from VJO), I got the feeling it was all getting a bit much, visually! While it’s fun to push the technology, it comes to a point where there’s just so much going on that there is no focus for the viewer. Time to scale it back!
My plan for the next one is to only display one or two video based clips, confined to a single screen, or perhaps spread in a partial mosaic type effect, and have the other screens pretty much be flat colour, though perhaps with a subtle corner shaded mask. Should create a more ambient effect and provide the needed focus.
There is one trick that I want to try out towards the end of the set that will involve a screen that covers the entire stage with some alpha blended particle effects. As the screens tend to be very defined, introducing images floating over and between them will radically alter the perception of the set up. May save that for the last song!
As well as going to the Loop Festival yesterday, I also popped in to the Concorde 2 to see VJ Spank doing his thing. He’s been working with the latest version of the streaming plugins and had two machines set up, one running vvvv and sending 800×300 video via ethernet to the other, which was running OpenTZT. There seemed to be a few problems with loss of connection now and then, due to switching patches, but when active it was streaming very smoothly. I’m adding a couple of minor features this week so look for a new release soon.
Today I’ve mostly been considering how to structure the internal data of PatchBox in order to allow the maximum flexibility and control from LUA. Was looking at wxVarient from wxWidgets, but not sure that’s quite right since it actually goes further than I need i.e. the contained type can actually change at run time, and I really only need the RTTI functionality. However, this poses and interesting problem that at the moment constructs like the virtual screens are defined as a nice class hierarchy that works very well in a C++ environment but not so well if you want another interface to be able to access the contained data.
It’s either a case of providing get/set functions throughout the classes to expose the data, which is probably going to introduce way too much overhead, or alternatively, move the data outside of the classes, though this does possibly mean the need for an observer interface. For the screens it wouldn’t be too much of an issue since every frame they run through and read the data and render the screens with no need for dynamic event triggering.
The other consideration is whether to have the data contained purely within the screen library, as it is at present, or implement a more global system as I had in the original PatchBox design. Both ways have their advantages. More thought needed!
