The future of OSC in Resolume

FFGL, OSC, GLSL. If you like abbreviations, this is the forum for you
User avatar
cosmowe
Knows Resolume better than the devs
Posts: 1597
Joined: Fri Mar 25, 2011 10:27
Location: cologne // germany

Re: The future of OSC in Resolume

Post by cosmowe »

I dont think that there is a massage like this...but...you can add for exaple a useless effect and timeline animate a value of it. You now could constantly readout the value on your osc device. Now you would know if the connection is lost.

greetings.
Cosmowe
Image Do you like outlines? Easy Outliner on Juicebar

moldywood
Met Resolume in a bar the other day
Posts: 9
Joined: Mon Oct 06, 2014 10:40

Re: The future of OSC in Resolume

Post by moldywood »

I guess instead of creating a whole new thread for this, it'd be nice to also send effect names i.e.. "/layer1/video/effect1/name <string>" (similar to the clip name OSC)

To me, the top tier of what changes in Arena are clips and effects types, and then the next tier down would be the parameters that control these. Since we are already getting clip names, fx names would make sense too.

I work in a duo when I VJ, and usually one of us controls the computer and the other the iPad (and other controllers), so it'd be nice to have the iPad person see what the computer guy sees on a very basic level. Communication during a loud show is damn hard, so the computer person telling the iPad person that he is changing effects on the fly is hard, and it'd be easier for them just to appear on the iPad. I figure the names and order of the parameters of each effect will be up to the memory of the iPad person.

alex_d
Met Resolume in a bar the other day
Posts: 9
Joined: Tue Nov 25, 2014 01:56

Re: The future of OSC in Resolume

Post by alex_d »

Since we're discussing OSC:

I use a lot of effects with animated parameters. When I bypass these effects or put their opacity on 0, R4 keeps sending out the changing values with OSC. Is there a reason why this happens?

If not I would like to propose being able to disable "useless osc messages" - I seem to suffer from packetloss on compositions with a lot of effects, I'm starting to think this could be the reason

Joris
Doesn't Know Jack about VJ'ing or Software Development and Mostly Just Gets Coffee for Everyone
Posts: 5185
Joined: Fri May 22, 2009 11:38

Re: The future of OSC in Resolume

Post by Joris »

The problem here is that what's useless to you, can be a necessity for someone else. For instance, a possible use case would be to remotely see the settings of an effect before it's 'unbypassed' again.

Of course you could put a toggle in the preferences, but with such an open protocol, before you know it you're stuck with pages of preference toggles you have to work through.

I think it would be better for us to focus on addressing the packet loss. Then you can leave it to the 3rd party implementation to either process the data or not as long as the effect is bypassed.

User avatar
Oaktown
Resolume honorary member
Posts: 2837
Joined: Tue May 08, 2012 15:19
Location: Oakland, CA

Re: The future of OSC in Resolume

Post by Oaktown »

Hey Alex_D, unless you're using the OSC output from Resolume, why don't you turn it off in preferences?

Also I agree with Joris that useless is a rather subjective notion when it comes to things like this so you're better off trying to write a patch on your own to deal with what you need.

alex_d
Met Resolume in a bar the other day
Posts: 9
Joined: Tue Nov 25, 2014 01:56

Re: The future of OSC in Resolume

Post by alex_d »

Hm yes, good point. I've found another solution that works for now.

The problem I had is that I'm routing the OSC messages from Resolume through a Processing sketch, towards 2 other addresses (touchOSC and Duration.cc) - I was simply forwarding a message each time the oscEvent() listener was called - a listener for individual messages -, which resulted in a very large quantity of messages being sent one by one (due to the large number of animated params). TouchOSC became extremely unresponsive as a result.

My current fix is to create a bundle with an arbitrarily defined size. I haven't figured out a way yet to let my script detect when an entire batch has come in (this might be due to limitations of the OSCp5 library) so that I can recreate the bundles that Resolume is sending

And also, I'm just a shabby DIY programmer :D

Joris
Doesn't Know Jack about VJ'ing or Software Development and Mostly Just Gets Coffee for Everyone
Posts: 5185
Joined: Fri May 22, 2009 11:38

Re: The future of OSC in Resolume

Post by Joris »

Btw, you can disable the OSC output of individual params via the Application OSC Map. It's a crapload of params to work through, and you'll find that there are some ghost messages that can never be turned off, but it should lighten the load a bit.

alex_d
Met Resolume in a bar the other day
Posts: 9
Joined: Tue Nov 25, 2014 01:56

Re: The future of OSC in Resolume

Post by alex_d »

Yeah I had thought of that as a backup plan ... but yeah it's a looot of params to go through :P

I've asked the creator of the OSCp5 lib for help regarding the bottleneck. Hopefully it should give me a better solution. Either way thanks for the help!

Zoltán
Team Resolume
Posts: 7088
Joined: Thu Jan 09, 2014 13:08
Location: Székesfehérvár, Hungary

Re: The future of OSC in Resolume

Post by Zoltán »

instead of filtering what messages you don't need, why don't you filter the ones you need, and drop the rest?
Software developer, Sound Engineer,
Control Your show with ”Enter” - multiple Resolume servers at once - SMPTE/MTC column launch
try for free: http://programs.palffyzoltan.hu

sleepytom
Hasn't felt like this about software in a long time
Posts: 236
Joined: Fri Sep 12, 2008 11:11
Location: sussex by the sea

Re: The future of OSC in Resolume

Post by sleepytom »

A huge improvement would be the ability to turn off (or on) individual messages via OSC itself. This would allow for truly dynamic control systems where the dataflow is controlled and kept within sensible range of what can be managed via wifi. Currently it is all or nothing so you cannot build a control system which has, for example, pages for each layer and only gets update messages for the controls exposed on that page. This means that effects automation results in huge dataflows resulting in packet loss issues when the packets you actually need to see are lost in a whole load of traffic which is unneeded at that point in the control system.

Post Reply