While building a simple art-net media player I got the problem that the data send with a dmx(artnet sender) node is not received exactly the same by a dmx(artnet receiver) node.
(see snapshot)
Am I doing something wrong or is this a known problem?
Is there a way around?
It is a resolution problem, you can only send a 0.000 to 1.000 in 256 steps (8 bit). User Kalle made a patch to send (and recieve) in 16 bit, using 2 channels, which gives you a lot more precision.
Ok, I got my good old casio calculator and I think I found the problem.
In the artnet receiver module the conversion from 8bit to 0.0000 to 1.0000 goes wrong. In stead of converting with 256 steps (=8bit) it converts with 255 steps.
See snapshot for calculation.
Am I calcualting right and is this a bug or do I miss something?
thanks for the close investigation. The first observation indeed looks like a bug.
The factor 255 is in fact a feature, not a bug. It allows the simple convention that 0.00 sends out DMX value 0 and 1.00 sends out DMX value 255. I just checked the source and the magic number 255 occurs on the sending side as well as the receiving side - I will investigate this further.
almost offtopic now:
please do not use the old modules west is referring to.
see kalle.Modules.DMX.Universal for manifold new ones.
Don’t investigate it Oschatz, the 255 is right.
Well, I can’t proper explain the reason in math and English, but the 255 is correct, otherwise the range would go from 0.0000 to 255*(1/256) (and that is lower than 1). We want a range from 0.0000 to 1.0000 (so AND 0.0000 AND 1.0000, all in 8 bits)
I attached a patch for 3 bits which should make it clear.
@Kalle, cool new DMX stuff :D
3bitsDemo.v4p (30.4 kB)
Okay, I now understand where it comes from.
Thanks West!
But it’s still annoying that the output is different from input…
A lightdesk sends 127 as 50%.
I’d like to get a 0.5000 from the ArtNet node.
For instance:
I use a dmx channel to rotate my picture.
I put the value in a Map with a output from -1 to 1.
If it gets 0.5020 my picture is rotated because the map outputs 0.0040…
hum… et what about rounding your values with a fract node, giving yourselve 0.50 and not 0.5020 ?
float entries with always be fixed to 255 steps and values.
Each DMX istep means about 0.4% increase. It is very simple to calculate:
DMX = 0 - 255
DMX/2.55 = PERCENT
PERCENT*2.55 = DMX
So exactly 50% doesn’t exist (127.5), it is either 127 or 128.
So like Karistouf suggested, rounding your values up or(or down) is the best way. On the other had… lowering your resolution from 256 steps to 100 steps brings down your accuracy even more!! :(
So you realy want some kind off filter connected to your rotation somewhere.
PS. Noted you are Dutch too, send me a PM with Skype/MSN contacts :)
DMXROunding.v4p (9.5 kB)
wouldn’t one of the Map nodes do the trick? i’m on linux right now so can’t check, but i think it’s this Map (Range) node that could remap 0-127-255 to 0-0.5-1?
edit: just realised, this solves the problem only for the 50% setting, isn’t it? could one do a value stretching easily with regexp or something similar maybe?
well, as west has suggested, should be easier or to round up, or to rewrite a good mapping by steps of 0.4%
but you will on video needs not be so happy from steps conversion I think. you will loose some definitions and you will have this kind of things:
''So exactly 50% doesn’t exist (127.5), it is either 127 or 128.
‘’
but peter444 seems to be in quite a need of precision on videos parameters.
a good other solution that takes a little time would be to remap but not with mapping functions, but doing like a grid or a dimmer law :
for each range of values, you will output the good value you need
aka: if incoming >0.14 and is < or equal to 0.18 you set your value to 0.18
this to be precise and have a customized table specific to your needs
going to 16bit sounds like a good idea here.
back in the days when i wanted to to control video synthesis thingies with MIDI i purposedly used only 120 of the 128 steps available. so you had have exact representations of 1/2, 1/3, 1/4, 1/5, 1/6, 1/8, 1/10, 1/12 and many more - which is quite helpful.
too bad vvvv settled on 255 which will get you only exact 1/5ths.
I use a dmx channel to rotate my picture.
I put the value in a Map with a output from -1 to 1.
If it gets 0.5020 my picture is rotated because the map outputs 0.0040…
that exactly are the purposes of my modules
use 2 DMX channels to transmit a value [ 0 ; 1 ]( 0 ; 1 ) with 16bit resolution
use 4 DMX channels to transmit Float with “Single” precision [ minInt ; maxInt ](Float with “Single” precision](Floating-point arithmetic - Wikipedia)__ [ minInt ; maxInt )
use 64 DMX channels to transmit a complete 4x4 Transformation Matrix
download complete bundle at kalle.Modules.DMX.Universal
Well… I spend a lot of time with West on msn and we tried a lot of options… not only for this part of my patch. Thanks West!
Because I didn’t want to use more than one dmx channel for rotating I choose to make the rotator ‘snap’ to 25% 50% and 75%. In other postitions you can hardly see the conversion error.
Bit by bit I’m getting there, with a little help from you all.
Thanks!
