Hi!
I'm currently working on a project in VB.NET to control Resolume (and other applications) with MIDI. The VB-application sends commands to Resolume to select a deck and then start a clip. This was no problem at all with Resolume MIDI-mapping.
But when a clip has been started, the VB-app will also send commands to a DMX-controller, MIDI and a PLC to activate some effects (lighting, par, smoke, sound-samples, etc.). I want these effects to be activated when the clip has reached a certain time- / progressvalue. I first started by catching the MIDI value from the clipprogressvalue, but the resolution was not good enough (0-127 over 15 minutes). So i looked up OSC and designed an UDP-server to catch the OSC-value "/layer4/video/position/values"; this was much better (32-bit float over 15 minutes). While playing the clip i noticed that the returned OSC-value is delayed with the actual value in Resolume. I think the problem is that the messages are sent at such a high frequency, the server can't handle the messages at the incoming message interval.
A great solution would be:
- Variable OSC-interval in Resolume in ms.
- A deadband for each int or float OSC value
- Time elapsed in minutes, seconds, 1/100 seconds for MIDI (eg.: #1/10=minutes, #1/11=seconds, etc. in values of 0-127)
Further more: by default ALL OSC-outputvalues are activated in Resolume. Please implement a button so all these messages can be disabled.
Dennis.
OSC Settings
Re: OSC Settings
We have to bounce this around the office.- Variable OSC-interval in Resolume in ms.
I'm not quite sure what you mean by this.- A deadband for each int or float OSC value
This is far too a specific feature to be implemented. We are in the very early stages of researching timeline functionality for Resolume 5, which would be a far more suitable and wider applicable solution.- Time elapsed in minutes, seconds, 1/100 seconds for MIDI (eg.: #1/10=minutes, #1/11=seconds, etc. in values of 0-127)
This has been requested before, and is on the to-do list.Further more: by default ALL OSC-outputvalues are activated in Resolume. Please implement a button so all these messages can be disabled.
Re: OSC Settings
Thanks for your reply,
I'll explain my deadband question.
If OSC is mapped for "/layer4/video/position/values" (or other values), Resolume returns a value of 0.0 - 1.0 in steps of 0.0000001. The OSC send-action is performed on change of a value, so it tries to send 0.0000001, 0.0000002, 0.0000003, etc... For the position of a 10 second clip, a crossfader or a opacity slider this seems like overkill.
If a deadband is implemented, the OSC send-actions are still performed on change but before sending, the value will be compared with the previous sent value. If the difference is less than the set deadband, the OSC send-action will not be triggered. If the difference >= the previous sent value, the current OSC-value will be send. So with deadband usage, Resolume sends less commands resulting in higher OSC performance (less actions, less delay and no data-loss).
Scaling the OSC-steps (eg.: instead of 0.0000001 --> 0.001) is another solution, but can be too rough for certian values.
In my opinion the user must be enabled to set the deadband for each OSC-map/value. This setting could be adjusted in the mapper-mode, bottom-left.
Greetings,
Dennis.
I'll explain my deadband question.
If OSC is mapped for "/layer4/video/position/values" (or other values), Resolume returns a value of 0.0 - 1.0 in steps of 0.0000001. The OSC send-action is performed on change of a value, so it tries to send 0.0000001, 0.0000002, 0.0000003, etc... For the position of a 10 second clip, a crossfader or a opacity slider this seems like overkill.
If a deadband is implemented, the OSC send-actions are still performed on change but before sending, the value will be compared with the previous sent value. If the difference is less than the set deadband, the OSC send-action will not be triggered. If the difference >= the previous sent value, the current OSC-value will be send. So with deadband usage, Resolume sends less commands resulting in higher OSC performance (less actions, less delay and no data-loss).
Scaling the OSC-steps (eg.: instead of 0.0000001 --> 0.001) is another solution, but can be too rough for certian values.
In my opinion the user must be enabled to set the deadband for each OSC-map/value. This setting could be adjusted in the mapper-mode, bottom-left.
Greetings,
Dennis.