wtf2osc in principal works now for me, but when sending 10 channel values 20 times a second (to get a 50 Hz refresh rate) it seems that the transmission to uDMX-interface is too slow.
From the docs i see that there a is multiply channel send method, but I am unsure what parameters the OSC String needs.
(When sending 1 channel it is /channelNo /i /channelValue; eg. /3 /i /243 for setting channel 3 to value 243)
What if I want to set 10 channels the same time?
Thanks for help,
Stephan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"multiple channels" in this case means OSC-bundles, these are multiple OSC-elements send together. I don't know if your software supports these, e.g. PD doesn't.
Can you tell me a bit more about your problem?
which OS?
which software do you use?
do the software and the OSC-server run on the same host?
what's the lowest and what's the highest channel you want to set?
did you build the uDMX yourself? if so, what layout did you use?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using vvvv with the OSC Send Patch running on WinXP. On the same machine is cyqwin running the wtf2osc python script. The uDMX is build by myself and already tested with DMXControl without any problems or speed issues.
At the moment I am controlling one LED PAR and want to set channel 1 to 3 (RGB) the "same time". Later I will add more LED PARs.
I read there is the possibility for sending OSC bundlesin vvvv, because wtf2osc prints "multiple send .." but my format seems to be wrong, because the channels don't react.
Stephan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm working with linux and I just tried setting 10 channels simultaneously in Pd.
I get an update-rate of about 50 times per second at <20 channels. This seems to be the maximum of the udmx.
I have no idea where your problems come from.
Does it all has great delays? Or is it just not simultaneous?
Have you tried another Windows-software, to make sure it's not vvvv?
Is wtf2osc listening on localhost(127.0.0.1)?
Again some code-tinkering, maybe it helps:
There are two lines starting with #print, lines 69 and 86, remove the '#' from the beginning and restart the script. When it has received multiple channels, it prints the first channel it sets and how many channels it sets.
If you set 10 channels beginning with channel 1 it prints: 'multiple channels: index: 1 length: 10'
If it's a software-issue you should see something like:
multiple channels: index: 1 length: 2
multiple channels: index: 3 length: 2
instead of:
multiple channels: index: 1 length: 4
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now I tried to use wtf2osc with Pd (also both running on one WinXP machine) and it works fine... I get very fast transmissions and fast responses.
So I guess it is a problem of either the vvvv-osc node or the vvvv-udp node which makes the timing issues.
It seems that when vvvv is calculating other things, the upd-send-node gets a low priority.
So first thanks for help, I will check out the vvvv things.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
wtf2osc in principal works now for me, but when sending 10 channel values 20 times a second (to get a 50 Hz refresh rate) it seems that the transmission to uDMX-interface is too slow.
From the docs i see that there a is multiply channel send method, but I am unsure what parameters the OSC String needs.
(When sending 1 channel it is /channelNo /i /channelValue; eg. /3 /i /243 for setting channel 3 to value 243)
What if I want to set 10 channels the same time?
Thanks for help,
Stephan
"multiple channels" in this case means OSC-bundles, these are multiple OSC-elements send together. I don't know if your software supports these, e.g. PD doesn't.
Can you tell me a bit more about your problem?
which OS?
which software do you use?
do the software and the OSC-server run on the same host?
what's the lowest and what's the highest channel you want to set?
did you build the uDMX yourself? if so, what layout did you use?
I am using vvvv with the OSC Send Patch running on WinXP. On the same machine is cyqwin running the wtf2osc python script. The uDMX is build by myself and already tested with DMXControl without any problems or speed issues.
At the moment I am controlling one LED PAR and want to set channel 1 to 3 (RGB) the "same time". Later I will add more LED PARs.
I read there is the possibility for sending OSC bundlesin vvvv, because wtf2osc prints "multiple send .." but my format seems to be wrong, because the channels don't react.
Stephan
I'm working with linux and I just tried setting 10 channels simultaneously in Pd.
I get an update-rate of about 50 times per second at <20 channels. This seems to be the maximum of the udmx.
I have no idea where your problems come from.
Does it all has great delays? Or is it just not simultaneous?
Have you tried another Windows-software, to make sure it's not vvvv?
Is wtf2osc listening on localhost(127.0.0.1)?
Again some code-tinkering, maybe it helps:
There are two lines starting with #print, lines 69 and 86, remove the '#' from the beginning and restart the script. When it has received multiple channels, it prints the first channel it sets and how many channels it sets.
If you set 10 channels beginning with channel 1 it prints: 'multiple channels: index: 1 length: 10'
If it's a software-issue you should see something like:
multiple channels: index: 1 length: 2
multiple channels: index: 3 length: 2
instead of:
multiple channels: index: 1 length: 4
Now I tried to use wtf2osc with Pd (also both running on one WinXP machine) and it works fine... I get very fast transmissions and fast responses.
So I guess it is a problem of either the vvvv-osc node or the vvvv-udp node which makes the timing issues.
It seems that when vvvv is calculating other things, the upd-send-node gets a low priority.
So first thanks for help, I will check out the vvvv things.