Hi!
I am playing with the thought of changing my live-visual-set from beta to gamma - but I am not sure, which “architecture/setup” to use.
My usecase: Playing visuals to songs of a live-band (about 60-90 minutes).
At the moment, my setup is one “main”-vvvv-patch which runs a renderer in fullscreen mode which has a picture of a logo. So normally, this logo is shown. For some songs I have vvvv-patches, which I load in the background and then switch the content of the renderer (as described in this post, which gave me the idea a long time ago: Switching between multiple patches ). [If it’s unclear what I mean, I can share my main-beta-patch]. The patches for the individual songs mostly contain video playback, 3d-patches and live-video-input.
So now I’m wondering how to do something similar in gamma. Is there a way to show the content of different patches in one “main-patch”? And would you recommend it? Or would it be easier to use the fresh start as an opportunity to use another system - kairos for example? Or is there something like a svvvvitcher-follow-up for gamma ( Svvvvitcher | vvvv )?
Thanks a lot for pointing to the similar discussion!
From a first quick reading it seems like the answer is: Yes, it is possible - but also quite complex :-)
So I am going to reflect on whether this is the architecture I am going to use. Because having a more structured approach in form of a timeline, kairos or sth. similar (maybe even having one big patch, if it works resource-wise) seems very tempting - and not having to deal with opening and closing patches during the show.
So thanks a lot! And it is really great, that it is possible in gamma!
Thanks a lot for your post! I haven’t looked into Spout yet - with Spout it would also be possiblie to use the output of beta-patches in gamma and vice versa, right?
This mix of vvvv-versions sounds very tempting - yet probably quite messy and ressource-hungry… But it’s very nice that this option is available!
In my experience it is quite smooth. I guess with modern multi core CPU’s it might even be beneficial, but I guess the devvvvs would need to weigh in on this, to get a good answer.
I use Resolume as a “mixer” and I have many patchs in beta and gamma sending spout out… its a pricy software and its not mandatory at all
I think building yourself a simple “mixer” and compile it as standalone app…
and from there you have full flexibility
Another quick option to test out this method is OBS
I think you could also put your different patches inside the main one, and use a manage process region around each to load and unload them. Probably quite a quick thing to test if you already have the patches
@catweasel : Thank you! Wow, that sounds really cool - and I think in the long run, this would be my ideal solution!
@andresc4: Thanks, that sounds like the perfect solution for me at the moment; and I already have a resolume licence (not the newest one, and only “Avenue”, but I guess it would work). My only concern is, that my midi controllers (and me!) will get confused, trying to work on 3 programs simultaneously :-) But I will give it a try!
You need 2 programs, LoopMidi and midioxse.exe
From loop midi you create as many virtual midi controllers as aplications you need
Example, Resolume, Beta, Gamma
and from midioxse you take you midi controler, and route a mirror of it to each midi controller, and then you open each virtual on each software
another option is OSC, you take your midi from Resolume and send OSC as brodcast, but only one software will be able to open a listener
the 3rd option is to use an instance of vvvv , take the midi and use ZeroMQ, I found the 1st option the easier one
Thanks a lot everyone!
I have managed to receive both gamma- and beta-patches in resolume via Spout - so think this will be my short term solution. And in the long run, I think I will try to recreate the beta patches in gamma and then use only gamma - either stand-alone with one big patch and regions, or in combination with resolume.
At the moment I am facing problems with spout both in gamma (very low framerate) and in beta (glitches), but I haven’t looked into possible solutions yet. If I don’t get along, I will open a new topic with specifically these questions.
Thought I’d weigh in on how I’m currently handling this. It’s very experimental right now, having many problems with OSC or Spout not starting properly, but it should all be solvable.
What I’ve done is create a standardised set of input/output nodes which you can import into any patch, and then I export the patch as an .exe. I then have an external program with a “nice” UI that dynamically starts and stops these programs, passing Spout and OSC addresses to send and listen to through command line arguments (don’t mind the placeholder images).
Pressing any of the buttons starts the selected patch and assigns it the channel you clicked on. Then you can access the output through spout channels “input0”, “input1” and so on, in for example Resolume or a master vvvv patch. I also have a standardised set of parameters sent over OSC that the patches get told to listen to. Overall fairly easy to use once the backend is set up, just take any patch and import the in/out nodes and it’s done.
I can’t share any code as it’s not in any presentable state whatsoever, but the idea shouldn’t be too difficult to replicate. There’s some issues regarding startup times, which vary from not even a second to half a minute, but I haven’t really investigated that yet. Might be windows defender being mad about a new .exe.
