Hello, just a quick question re OSC . I am sending OSC values between 0 and 1 to a fader in the virtual console. I expected 1 to be max ie. 255 on the slider however it appears .999 gives 254. A value of 1 sends the slider to 0 when I expected it would yield 255. Curious why this is working like this?
Thanks,
Jim
An OSC question
Curious indeed. Which OSC controller are you using ? Anything that I can test myself ?
I am sending OSC data using Pure Data. For example if you create a slider that has a range 0 to 1 and send the data using OSC at the top of the slider the value interpreted by QLC is 0 ? The behaviour is the same if I just send numbers directly. For example sending .999 QLC interprets this as 254, 1 as 0?
Strange indeed.
Strange indeed.
Can you sniff the network traffic and send me an email with the trace ?
I've got an idea but I need to double check it.
I've got an idea but I need to double check it.
Just as additional info...
I do not see this behaviour..
Control is correct for full range from 0 (0) to 1 (255) using TouchOsc with my own template and QLC+ workspace setup.
I do not see this behaviour..
Control is correct for full range from 0 (0) to 1 (255) using TouchOsc with my own template and QLC+ workspace setup.
Thanks for the help. I don't have your email address Massimo so attaching a file with hex dump of osc data from a slider that was moved from 0 to 1 in Pure Data and sent via OSC to QLC+ .
- Attachments
-
- wireshark_osc.txt
- (3.9 KiB) Downloaded 117 times
I connected Pure Data via OSC to TouchOSC on my phone and TouchOSC interprets the slider data corectly. ie. a slider in PD when at 1 sends the slider in TouchOSC to 1 not 0 as happens in QLC+.
My quick look at your wireshark data shows some interesting things..
The sequence is....
The first value is: int32 = 0
..next is: float32 = 0.007878
..increasing ...
..2nd last: float32 = 0.99212
..last value is int32 = 1
Massimo... a quick look seems to show that the OSC input is assumed to be always a float?
The sequence is....
The first value is: int32 = 0
..next is: float32 = 0.007878
..increasing ...
..2nd last: float32 = 0.99212
..last value is int32 = 1
Massimo... a quick look seems to show that the OSC input is assumed to be always a float?
That's exactly what I expected to find.
I read the poor OSC specifications again, and technically it is possible...but it doesn't make any sense.
QLC+ consider only floats, yes, but when a controller sends data it should use always the same type. 0.000000 and 1.000000 can be sent as float too.
Now if I introduce a workaround to consider integer values 0 and 1 like floats, I would probably mess up some potential future cases.
For example a controller using only integer values could use value 0xFFFFFFFF to indicate DMX value 255. So value 1 would be scaled down to 0. Which is not wanted.
I need to think about a solution, but I would prefer to talk to the guy who wrote the PureData OSC extension.
I read the poor OSC specifications again, and technically it is possible...but it doesn't make any sense.
QLC+ consider only floats, yes, but when a controller sends data it should use always the same type. 0.000000 and 1.000000 can be sent as float too.
Now if I introduce a workaround to consider integer values 0 and 1 like floats, I would probably mess up some potential future cases.
For example a controller using only integer values could use value 0xFFFFFFFF to indicate DMX value 255. So value 1 would be scaled down to 0. Which is not wanted.
I need to think about a solution, but I would prefer to talk to the guy who wrote the PureData OSC extension.
@jim, I just pushed a patch online. If you compile from sources please check it out
Thanks Massimo and Rowan. I have always used the .deb version. Is the patched version here http://sourceforge.net/projects/qlcplus ... z/download