David Butler

Attached are the latest versions of my native C Art-Net externals. Version 0.9 has no new features, but the objects are now compatible with Windows. I haven't done extensive testing, so the objects should still be considered beta. Please don't use for any absolutely critical shows, although you should be fairly safe on the Mac side. Would love to hear from Windows users regarding stability and performance.

CC Attribution/Non-commerical/Share-alike licensed. Supports Max 5 and 6, although help files use attrui which won't show up in Max 5.

native-art-net-objects-v0-9-now-supports-windows

We are using the 0.5 version pretty intensively on an interactive installation but have some latency problem.

we have a bunch of sensors that trigger sound and light. We are broadcasting on 3 different artnet universe (3 instance of imp.dmx.artnetout) to control light cues on a GrandMA lightboard. The sound always trigger on time with no delay but the dmx starts to lag when there is too much activity (tried unicast with the PC version, but it doesn't solve the problem). the network doesn't look busy so I don't think the problem is there. The cpu usage is bellow 50%. each sensor activity modifies some DMX channels so that can end up it quite a few changes per seconds when there is activity in the installation but from what I understand you are limiting the broadcast speed @ 44Hz so I guess it shouldn't be a problem...

do you have any ideas on what could be done to reduce the problem? any suggestion would be welcome :)

I just tried the PC version that seems to work as expected (but we still have the same problem)

hello,
We are using the 0.5 version pretty intensively on an interactive installation but have some latency problem.
we have a bunch of sensors that trigger sound and light.  We are broadcasting on 3 different artnet universe (3 instance of imp.dmx.artnetout) to control light cues on a GrandMA lightboard.  The sound always trigger on time with no delay but the dmx starts to lag when there is too much activity (tried unicast with the PC version, but it doesn't solve the problem).  the network doesn't look busy so I don't think the problem is there.  The cpu usage is bellow 50%.  each sensor activity  modifies some DMX channels so that can end up it quite a few changes per seconds when there is activity in the installation but from what I understand you are limiting the  broadcast speed @ 44Hz so I guess it shouldn't be a problem...
do you have any ideas on what could be done to reduce the problem?  any suggestion would be welcome :)

 I just tried the PC version that seems to work as expected (but we still have the same problem)
thanks for the good work!

Careful, imp.dmx.artnetout is a different object, using java to send data. The imp.artnet objects are native C code and much more efficient.

I've not seen this happen before, how much is the lag approximately?

I have the same behavior with your new C code version... when there's a lot of activity, we can get a lag of up to 3 seconds.... we are sending the whole 512 block. was imp.dmx.artnetout the right object to use?

I have the same behavior with your new C code version...  when there's a lot of activity, we can get a lag of up to 3 seconds.... we are sending the whole 512 block.  was imp.dmx.artnetout the right object to use?


Can you replicate the lag when disconnected from the network and sending Art-Net to localhost (127.0.0.1) ?

Not easily. I need to send the data to the computer running the GrandMA software to be able to notice the lag. I have a message box where I set the value of the buffer before sending it to the dmx object and cannot see the lag from there....

I did a separate test patch sending changing values to my 3 artnet universe and that is working fine...

thanks for helping me on this, I've been scratching my heads for the last weeks on this...

Not easily.  I need to send the data to the computer running the GrandMA software to be able to notice the lag.  I have a message box where I set the value of the buffer before sending it to the dmx object and cannot see the lag from there....
I did a separate test patch sending changing values to my 3 artnet universe and that is working fine...
thanks for helping me on this, I've been scratching my heads for the last weeks on this...


If you can't detect any lag when sending to local host then that shows there's nothing wrong with the object so the culprit is either your network or the MA. Are you running MA2onpc?

yes. it's MA on PC. as said above, when I run a test patch (without the rest of our installation stuff) that sends changing value to 3 universe to the MA I can't reproduce the problem.... could I be "clogging" the dmx object with too many messages?

with the native version, when I monitor the rate output from the dmx object, it sometimes get as low as 2fps. what can cause that?

yes. it's MA on PC.  as said above, when I run a test patch (without the rest of our installation stuff) that sends changing value to 3 universe to the MA I can't reproduce the problem.... could I be "clogging" the dmx object with too many messages?
with the native version, when I monitor the rate output from the dmx object, it sometimes get as low as 2fps.  what can cause that?


Can you post the part of your patch (the one that lags) with the art-net object so I can see?

sure. It may take a little while (need to remote access the installation machine - I.m not on the site right now) do you have a private address I can send it to?

sure.  It may take a little while (need to remote access the installation machine - I.m not on the site right now) do you have a private address I can send it to?


Send it to david@theimpersonalstereo.com.

ok. I sent you the project and some more info via email. thanks.

ok.  I sent you the project and some more info via email.  thanks.


I finally solved my problem! We had quite a few line object with a grain (wrongly) set to 1ms (ouch). I think that was generating too many message in direction of the dmx object and creating a traffic jam in the message queue. The installation is now working nicely (with the native PC version, which seems to behave nicely)!

http://www.radio-canada.ca/nouvelles/arts_et_spectacles/2012/12/05/003-luminotherape-quartier-spectacles.shtml

many thanks for your time and for the artnet stuff!

I finally solved my problem!  We had quite a few line object with a grain (wrongly) set to 1ms (ouch).  I think that was generating too many message in direction of the dmx object and creating a traffic jam in the message queue.  The installation is now working nicely (with the native PC version, which seems to behave nicely)!
if you want to have a look: http://www.radio-canada.ca/nouvelles/arts_et_spectacles/2012/12/05/003-luminotherape-quartier-spectacles.shtml
many thanks for your time and for the artnet stuff!
philippe


A bit of a noob question here. I just got my eDMX-1 from DMX-king, which is an art-net interface, and I'm having a hard time getting the lights working (and a harder time figuring out where the problem is).

eDMX-1 (with default settings listed below)

2 x Chauvet SlimPar Pro Tri (both set to 4-channel (dimming, RGB) mode and one starting at address100 and the other at address200)

So in looking at the imp.artnet.controller help file (which appears to be missing a bpatcher in this release (imp.about.maxpat)) in order to pick the channel I send a "channel 1 xxx" message. Can't tell the difference between channel and setchannel messages, or what the first argument in that message is (the "1").

For the net/subnet/universe, I would set all to 0 given my default settings (below), but where I'm really struggling to understand is the unicast/ip address. I've not configured my eDMX-1 in any way, so it literally just has the ethernet/miniUSB cables plugged into it. Does that mean that I should set @unicast 1 and @unicast_ip 192.168.0.111 and that's it? Is there anything I need to do in network settings/configuration?

As for the messages themselves, would I send channel value pairs? (ie 100 255, 101 255, 102 255, 103 255).

The eDMX-1 comes with these default settings:

Art-Net DMX Universe 0 [Subnet 0, Universe 0]

A bit of a noob question here. I just got my eDMX-1 from DMX-king, which is an art-net interface, and I'm having a hard time getting the lights working (and a harder time figuring out where the problem is). 

My equiment:
eDMX-1 (with default settings listed below)
2 x Chauvet SlimPar Pro Tri (both set to 4-channel (dimming, RGB) mode and one starting at address100 and the other at address200)
MacBookPro with Mountain Lion & Max6

So in looking at the imp.artnet.controller help file (which appears to be missing a bpatcher in this release (imp.about.maxpat)) in order to pick the channel I send a "channel 1 xxx" message. Can't tell the difference between channel and setchannel messages, or what the first argument in that message is (the "1"). 

The eDMX-1 comes with these default settings:
￼
IP Address 192.168.0.111
Subnet Mask 255.255.255.0
Default Gateway 192.168.0.254
￼
￼￼Network Mode Custom IP address
Art-Net Operation Mode DMX Transmitter
￼
Art-Net DMX Universe 0 [Subnet 0, Universe 0]
Art-Net Merge Mode HTP


Don't worry about the missing bpatcher, it's just my standard header logos I put in my releases. Will embed it for the next version.

Firstly there are two transmission modes, @auto 0 and @auto 1. When auto is on, the object automatically takes care of sending the objects internal buffer out via Art-Net packets. This is done at a maximum rate of 44Hz, but when data is unchanged at a rate of 0.25Hz. When auto is off, Art-Net packets are sent out whenever the data is changed or when a bang is received. Therefore if a repeated output is desired, a metro should be connected to drive it at the required frame rate. However, the object will still not allow any transmission above 44Hz.

To send data, send a list of ints (0-255). This will be assumed to start at channel 1.

The 'set' and 'setchannel' messages are to be used when @auto is off. All they do is set the internal buffer without sending a packet. If used when @auto is on, their operation will be the same as the 'list' and 'channel' messages. The first argument in the 'channel' and 'setchannel' messages is the channel, and the second is the value. Only a single channel/value pair can be sent with this message, although it might be an idea to add functionality which would let it send a list of channel value pairs.

If you're only sending to one Art-Net device, unicast is the easiest option. You're correct in your thinking with @unicast and @unicast_ip. Art-Net in unicast works just like OSC, except you don't need to set ports as all Art-Net traffic uses port 0x1936. Broadcast mode is more complex and requires settings custom IP addresses and changing router settings. It's better for large entertainment networks though, where numerous devices will be listening to the same Art-Net data.

The 'set' and 'setchannel' messages are to be used when @auto is off. All they do is set the internal buffer without sending a packet. If used when @auto is on, their operation will be the same as the 'list' and 'channel' messages. The first argument in the 'channel' and 'setchannel' messages is the channel, and the second is the value. Only a single channel/value pair can be sent with this message, although it might be an idea to add functionality which would let it send a list of channel value pairs. 

If you're only sending to one Art-Net device, unicast is the easiest option. You're correct in your thinking with @unicast and @unicast_ip. Art-Net in unicast works just like OSC, except you don't need to set ports as all Art-Net traffic uses port 0x1936. Broadcast mode is more complex and requires settings custom IP addresses and changing router settings. It's better for large entertainment networks though, where numerous devices will be listening to the same Art-Net data.


Ok, so my physical and configuration setup/understanding is correct. It's just a matter of sending the right message(s).

I'll probably use @auto 1 just to simply things and not need to worry about banging/metro stuff.

Here's a the patch I'm using and it's still just spitting out "Error: Couldn't send packet." messages. (on my eDMX-1 the activity LED seems to flash once every 5ish seconds (not 4 seconds) and not in sync with the max window error message which happens every 4 seconds (or more if I'm manually sending data).

Ok, so my physical and configuration setup/understanding is correct. It's just a matter of sending the right message(s). 

Nothing wrong with your patch from my end. Could you try changing the @unicast_ip to 127.0.0.1 and see if you get the same error then?

No error when I do that. No network activity on the interface for either one.

When I change back to my ip address and start sending messages no errors appear for about 5 seconds, then a burst of them come through. Then they come regularly after that. Again, no network activity on the eDMX-1.

https://cycling74.com/forums/controlling-dmx-lighting-natively-using-inexpensiveisolated-hardware

matheusleston is suggesting some network configuration:

I've not messed with mine at all, and looks as attached.

Should I change network/ethernet settings?

In looking back on this thread:
https://cycling74.com/forums/controlling-dmx-lighting-natively-using-inexpensiveisolated-hardware

matheusleston is suggesting some network configuration:
http://d.pr/i/xXOf

Should I change network/ethernet settings?


Your network is DHCP, and it's assigning addresses in the 169.254.x.x range. Your eDMX device has an IP of 192.168.0.111, so the router can't communicate with it. Check the 'Network Mode' setting on your eDMX to see if it has a DHCP mode. If it does, enable it. Otherwise, give it an address that begins with 169.254.

Can't see anything about DHCP in the manual, but I'll try changing the ip to that range. Need to go over to a friends with windows as the config utility is windows only (and isn't playing nice with Wineskinning).

So that 169.254.x.x range is specific to my laptop? To this time I plugged it in? Per reboot?

On my iMac the IP address listed under ethernet is 192.168.0.2

And is this ip/ethernet thing something that one has to do every time you use an art-net device or once I change it to 169.254 it's good from then on? (unless I go onto another machine)

The 169.254.x.x range is a specified range for private IP addresses (ones which are reserved for non-internet use). 192.168.x.x and 172.x.x.x are other ranges reserved for this purpose. Your router will assign an address in this range for your laptop which will last as long as your router is set to make it last (the expiry time).

I would say though, that the 169.254.x.x range is most commonly seen on devices that have failed to find a DHCP server, and have assigned themselves their own IP. It's the default range for self-addressing on both windows and OS X.

Took some wrestling but configured the eDMX to have 169.254.x.x with a subnet of 255.255.0.0 and now it defaults to stuff in the right range.

Was some easy/awesome once the network stuff was setup.

Took some wrestling but configured the eDMX to have 169.254.x.x with a subnet of 255.255.0.0 and now it defaults to stuff in the right range. 

Was some easy/awesome once the network stuff was setup.


Native Art-Net Objects V0.9 - Now Supports Windows