OSC message Fade - float not allowed?

[Daan Hazendonk]

Thank you SO much for all the great work on V4! I'm a very happy child again YAY.

I just tested the OSC fade function (1D fade), which is really great addition. However, I cannot seem to enter any float value (0,0 or 0.0).
If I enter any point or comma, the interface hangs. I have to remove the point or comma to do anything else in the cue properties panel.
Is this not (yet) implemented or is there something I'm missing?

Thanks!

[Chris Ashworth]

Thanks Daan!

Yes, this is not (yet) implemented. But it is on our list to support floating point values in OSC fades, hopefully sooner rather than later.  At the moment it will only send out whole number integers and fade among whole number integers. (This is an artifact of basing the technique on what we did for MIDI fades, which makes sense there, but we need to update it to allow floats for OSC.)

Cheers,

Chris

[micpool]

I just had the same problem using network cues to control Resolume Arena 5 which expects all OSC values  to be floats in the range 0.0 to 0.1

The workaround until this is fixed is to use our old friend OSCULATOR.  Route out of QLab to  Osculator using a #v# of something like 0 to 1000  and  scale the incoming arguments to output to your application port 0.0 to 0.1 which should be adequate for say an video  intensity fade or an audio fade as it provides a fader resolution of 1000 steps.

The other thing that becomes apparent is that is likely when QLab allows floats it will have to have some mechanism for defining the resolution of the output steps.  For instance in resolume the anchor x parameter uses values of 0.0 to 1.0 to represent pixel shifts of -8192 to +8192. As most screens will only use a tenth of this range to move an image from side to side (2000 pixels) we need to send 2000 OSC messages  between  float values of 0.4 and 0.6 to get smooth motion across the width of an HD screen.

In OSCULATOR that means scaling a 1 to 10000  input to 0.0 to 1.0 output, with QLab outputting integer values between 4000 and 6000.  

When this is implemented directly in QLab it will require 2000 float values to be sent between 0.0 and 0.4.

Could the resolution just be defined by the number of decimals in the float values?  e.g for this example we would define From in QLab to 0.4000 and To as 0.6000. 

For coarser parameters  If we just needed  100 steps across the whole range  min would be 0.00 and max would be 1.00

Mic

[Daan Hazendonk]

Hi MIc & other interested,

That OSCULATOR solution is awesome.
I do agree it would be necessary to have a mechanism for handling the resolution output steps. I also would like to use Qlab for controlling Resolume Arena.

I have a tip for those who want an other solution: Vezér is also super-handy in cue-based timeline-OSC (and it has a function where it recalculates everything to f 0.0 - 1.0).
Lets get groovy! :-)

Daan


Op maandag 21 november 2016 01:16:56 UTC+1 schreef micpool: