Resolume Forum

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

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.

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

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.

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.

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

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.

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

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!

instead of filtering what messages you don't need, why don't you filter the ones you need, and drop the rest?

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.