ARTNET patch

Hi , i would definetly state that QC lacks output to physical devices, such as lighting fixtures (or explosives...). DMX protocol is the mostly used in "pro" environments, nightclubs or festivals, theaters... However, most DMX usb cards that you can plug to your mac use a FTDI chip, which is crappy, and which is apparently from a company you had problems with... This has led the development of a potential " DMX usb" patch (for the enttec one that smokris owns) to nowhere... since it uses the serial port for communications.

After some chat with one of vvvv's DMX supergod (aka kalle), it just seems that the handier and easier protocol to deal with DMX is now Artnet, which uses UDP packets to transmit DMX information.

Have a look at this (quite cheap) card from Enttec, that takes UDP packets as an input and outputs DMX... note that there are plenty other cards (from 100$ to 2000$) from other manufacturers.

So I'm thinking: if some really need DMX output from QC, how about considering an Artnet patch - that is virtually compatible with ANY artnet hardware ... ?

here's the ArtNet spec.:

gtoledo3's picture
Can't DMX take MIDI output

Can't DMX take MIDI output with fairly little pain/conversion?

It may be worth looking at Memo's QC camera/midi composition setup (google that I guess)?

I know I use this to trigger midi in garage band occasionally.

Could that be a starting point for this?.... I apologize if I am throwing out something that isn't applicable to your situation, because I'm definitely speaking from a position of limited knowledge on this issue.

It seems to me that if I had my old lighting setup (from a stint of having a studio/production stage) to my memory, that all it would have taken would have been to setup Memo's web piano example to get midi output,and plug it into a converter box I had. Now, I imaging that I would get a jumble of crazy activity from the lights without a lot of refinement, or that it might be better not to use the camera as the controller...

franz's picture
7 bit is not enough

MIDI is a 7 bit protocol, while DMX is 8 bit. When just dimmming a light, you could easily rely on MIDI then convert it with a lanBox for instance.

However, when working with multiple moving lights for instance (such as Martin Mac xx), you would typically use 9 x 8bit channel just for 1 light, where 7 bit precision is out of the question (360 degrees / 128 steps = 2.8.. degree, while 360/ 256 = 1.4.. degree, not to mention that some PTZ lights use 2 channels per value for some extra precision : 360/ 512 = 0.7 degree minimum movement.)

Take 10 moving lights, a bunch of strobes with color changer (5channels each) and you end up using 100+ channels of 8 bit data, minimum. With such a channel number, MIDI is definelty out.

So no, i'm asking for real DMX output from QC via some nice free protocol: ArtNet. (Memo's webcam piano has nothing to do with this.)

gtoledo3's picture
That really sheds some light

That really sheds some light on that! Thanks for the explanation of the difference there.

I apologize if throwing out the webcam Piano thing was irrelevant... all I was meaning was that I could hook up a light using that setup, and basically control it in some way through that composition by waving my hand in front of a webcam. I understand you are asking for a complete protocol...

That's really an interesting explanation.

mfreakz's picture
Gooder, Larger, faster...

That could be great for all of us (musicians, multimedia artists, Art and stage directors... ;) is to have, one day, a solid, large and quick data protocol ! As CWright love to call them (for Patches) "One Protocol to rule them all" ! Our works are precisely crossover interactive management ! To output QC datas to physical devices, OSC seems to be a good choice not ? So the matter is is there an OSC2DMX an OSC2Midi an OSC2everything box on the market ? Maybe i'm wrong, Franz, could you tell us what's OSC quality in bit transfer ? If it is a good, large and quick data transfer protocol, may be we could ask and expect an Arduino box to convert OSC2DMX as there is an Arduino Box with midi output ?

franz's picture
OSC = UDP / ArtNet = UDP

OSC is a protocol that sends control data through UDP packets. UDP is fast - although it is said to be less reliable than TCP-IP , as packets can get lost-

ArtNet is a protocol for sending DMX values via UDP packets. So it is basically the same thing as OSC, but with differently formatted packets.

I assume that being able to send raw UDP packets from QC, but ArtNet formatted, is enough to control DMX lighting. Maybe a javascript value formatter then a simple UDP sender would be the right combination of patches. A proper dedicated patch is always better, imho.

There's an Arduino box that converts DMX messages to Analog/digital values, and also a DIY arduino DMX shield that can output DMX. However, you would still need an Arduino (with ethernet input, not serial/usb), which is really too "tinker" style.(plus learn to code arduino so that it actually converts packets the right way).

It is already possible to make video shows for 10000+ ppl, using only QC (read: hassle-free coding), ArtNet output would simply allow to control the lighting gear as well (wirelessly, of course)... and skip the light-guy (who always wants to put his stronger light in the middle of your projection)

639me's picture
equipment that use two dmx

equipment that use two dmx channels are 16 bit, meaning in effect a resolution of 65536. most up to date moving lights use 16 bit for most of their parameters, not only pan/tilt, but iris, gobo rotation / indexing, cmy color mixing etc. for a total of around 30 dmx channels. if anyone is looking into this, it would be very interesting to be able to receive dmx / artnet also. and keep in mind that 16 bit channels are desirable.

smokris's picture
16bit DMX/Art-Net

639me wrote:
if anyone is looking into this, it would be very interesting to be able to receive dmx / artnet also. and keep in mind that 16 bit channels are desirable.

Interesting. We're going to be looking into this. :^)

Can we assume that 16bit DMX/Art-Net channels are always consecutive and in the same order (i.e., channel 42 = HSB, channel 43 = LSB) ?

639me's picture
skipping aliens..

yes, at least the lamps i've used. that are sgm, robe, martin and high end. but in the device patching utilities in lighting consoles (all xp...), there is the possibility to define where the lsb offset is addressed. might be a good idea to have a look into too? or to start with, the 'dmx charts' of some lamps. if it's not too alien to look into, try grandma onpc 5.910 on this site:[parent_gruppe]=215&tx_lightpowerpdb_pi1[produkt_id]=1&tx_lightpowerpdb_pi1[bereich_id]=2&cHash=4c641d52cf#

or compulite vector pc 3.15.02 here:

those are two popular consoles for theater and show business, capable of controlling 16-64 universes, 512 dmx channels each...

or if i learn to take screenshots in xp, i could help you that way.

another thing to mention that distinguishes dmx from midi is that it transmits the whole range of data continuously, up to 44 times a second. not only when a channel is updated. i'm not too heavily into that side to it though, so anyone please correct me if i'm wrong. i'm more interested in the aesthetics, and to actually bring the equipment that i will use..

smokris's picture
So I've been reading through the Art-Net spec...

...and I think Art-Net may be the alien here. (Would The Real Art-Net Please Stand Up?)

From the Art-Net spec:

Products implementing Art-Net should default to the Primary IP address of 2.?.?.?.

Why do they use rather than the RFC1918 standard nonroutable network (But later it describes that the "secondary" IP is Bizarre.)


Should we implement the "Peer to Peer" mode or the "Server to Peer" mode or both? "Server to Peer" would be a lot more work since we need to transpond a ton of packet types, whereas in "Peer to Peer" mode we need only send ArtDmx packets (Page 19 of the spec), so I'm leaning toward just "Peer to Peer" mode. Would this severely limit functionality?

639me wrote:
but in the device patching utilities in lighting consoles (all xp...), there is the possibility to define where the lsb offset is addressed.

Gotcha. Specifying both the LSB and MSB channels independently should be straightforward if we use a keyed structure...

I'm thinking about the following design:

(There's no actual code behind this patch, it's just a visual preview.)

  • The Channel Structure input is a keyed structure, where the structure's key represents the output ArtDmx channel (0 to 511), and the structure's value represents the value to send to that channel (0 to 255). You can also specify comma-delimited keys, representing a 16bit composite channel consisting of two arbitrary 8bit channels. In this screenshot, "42" is the channel to which the HSB is sent, and "79" is the channel to which the LSB is sent.
  • Network is either (Primary, "Network Switch Off") or (Secondary, "Network Switch On"), per the Art-Net spec.
  • Sub-Net and Universe would each allow selections from 0 to 15, per the Art-Net spec, allowing a total of 256 possible Universes.

Does this look right? Anything missing?

Anybody interested in sponsoring the development of this patch? ;^)

ArtNetDraft.png57.49 KB

639me's picture
on the art-net side of it, i

on the art-net side of it, i can't comment. maybe only that i've seen that there's normally a subnet mask setting too, which is i think. i've never really worked with art-net. the dmx side looks just fine. for reference, there's an iphone app called luminair, that transmits wireless art-net i'm sure there could be money made on this, both on the transmitter and especially if you made an art-net receiver. but i'm no business man!

smokris's picture
subnet masks

639me wrote:
maybe only that i've seen that there's normally a subnet mask setting too, which is i think.

According to the Art-Net spec:

All Art-Net implementations require a Sub-Net mask of

So I'm thinking that since this can't be changed, we don't really need an input for it. Or do actual implementations of Art-Net devices differ from this?

(BTW the subnet mask is reflected in the interface prototype above: in "", the "/8" means the same thing as "" --- that is, the first eight bits of the 32-bit value are to be interpreted as the network, and the remainder is to be interpreted as the host.)

smokris's picture
Art-Net Receiver

639me wrote:
for reference, there's an iphone app called luminair, that transmits wireless art-net

Very cool, thanks for the link.

I think it would make sense to also make a Kineme Art-Net Receiver patch. This would essentially be a mirror image of the above patch, listening for Art-Net broadcasts on the selected Interface/Network, and providing a keyed structure of the 512 values of the selected Sub-Net/Universe.

With these two patches, I think you would be able to recreate the essential functionality of Luminair (but building a slick GUI like that in QC would be pretty tricky :^) ).

franz's picture
right and tight

your diagram looks perfectly right. the 16bit trick is particulary interesting. (Maybe an option to set inputs a INT or FLOAT would be nice, as many of the QC patch take normalized inputs. - but that's just a thought -)

With the Enttec ODE, you can set the address to something like 10.x.x.x manually with the NMU firmware editor. So network doesn't seem to be an issue.

smokris's picture
Raw Integer Value vs. Normalized Float Value

Cool, franz. So we should add an input to both the Sender and Receiver, to switch between Raw Integer / Normalized Float inputs/outputs?

And, yeah, after dozens of hours burned failing to get the FTDI crap to work, I've officially given up and listed my USB-DMX interfaces on eBay and ordered the Art-Net interface you recommended. This seems like a more realistic goal, since ethernet is already known to be working in Mac OS X :^P . I'll try to cook up something soon.

franz's picture
normFLOAT = sweet for 8 or 16 bits

yes, an input switch would be dammm useful. Esp. because you can work the same way with 8bit or 16bit. Just specifying 2 addresses in the structure (like you showed) would switch to a 16bit mode...

Hopefully you'll be able to sell back your DMX USB pro, which is super-great for MaxMsp users (with the proper external tho')

tobyspark's picture
just to second franz

my eyes were totally opened to this at node08. i still haven't done a project that needs it, but yep it was a definitely a big moment hacking a whole lighting rig via wifi (ie artnet) and rapid prototype patching/programming.

second paragraph of the node08 bit:

franz's picture
interesting ArtNet link

and they also talk about whiteshark, which is said to be the right tool when working with artnet ( source: shwarzpeter's author -DMX artnet PC app-, karistouf)

franz's picture
awe !

thanks for the release. currently messing with it ....

edit: it is working out of the box ! congrats steve now i'll just have to get my hands on some moving lights to test the 16bit mode. Thank you so much...

cwright's picture

glad it worked out of the box :) we dumped a lot of time into testing it to make sure stuff went smoothly, but there's only so much we can do... :)

639me's picture

didn't realize you still had a priority on this! i'll test it in january while touring.

son_ne's picture

great tool! ...if it would work... i was looking for a dmx input for quartz composer. so i was really amazed to find your patch. but: nothing. what do you mean by other than ArtDMX are ignored? what IS ArtDMX? so i receive ArtNet-data but the ArtDmxReceiver patch doesn't receive anything. any ideas? greetings from berlin, h*ns

cwright's picture

We discovered a bug in DMX receiving shortly after release -- we've got a fix in 1.1, which we should be releasing shortly (next day or two, if all testing goes well).

artdmx is DMX data over art-net.

son_ne's picture

oh yeah! i am very much looking forward to this. in the meantime i found, that your artdmx packets have a version number 3584 in their header - instead of 14 which is the actual version... since this is the only difference to the enttec artdmx-packet i thought this might be the bug? right now i am trying to change this value with ettercap... greetings, h*ns

cwright's picture

We just released Kineme ArtNetTools 1.1, which should address this problem for you -- please let us know how it goes :)

(by the way -- yes, the version numbers on incoming and outgoing packets were reversed (0x1400, instead of 0x0014), causing the problem you noticed -- this is now fixed)

weevil's picture
Re: ARTNET patch

I'm trying to control a couple of lights with Quartz Composer in conjunction with a VDMX set. I made the mistake of getting a Enttec DMX USB pro first, which I thought maybe I could use with the Max patch that's floating around. No luck. After reading the forums here, I'm planning on getting rid of the USB box and getting an ethernet one and using ArtNet.

Which Box should I get?

Is there an example quartz compostion using the ArtNet patch that I could look at- All I need to do in this set is fade colors on an RGB led can and turn on and off a UV led bar. Simple stuff. I'd like to be able to do it from within VDMX though.

gtoledo3's picture
Re: ARTNET patch

The sample compositions are available here:

Look at the attachment that says "compositions" in the title.

You should be able to manage your requirement fine. I don't really have any kind of opinion on hardware for your scenario though.

memo's picture
Re: ARTNET patch

I have the Enttec ODE (the blue box) and it works great with this plugin. Enttec's own admin/config software is crap though, it just wouldn't connect to my box and I thought it was faulty, but franz was helpful enough to show me that the box was actually working and didn't even need any config. There are much more expensive boxes out there (which usually support multiple DMX Universes), but for one universe (512 channels) this box works great.

dust's picture
Re: ARTNET patch

so im about to try this artnet thing out. next month. do you think this is the best box to get price wise ?

i have a mate building a crazy sound stage for in hollywood for filming music videos etc... so far its complete with blue screens and rear projection lycra for projections.

we have about 8 dmx lights and a few lasers hooked up to dmx mixer. unfortunately the mixer doesn't seem to be doing anything. so i suggested a computer be used to control everything.

so i kind of put my self in this position of being the guy who makes the lighting macros but really have no clue whats needed to get this all working with qc..

just one of the boxes and im good to go ?

gtoledo3's picture
Re: ARTNET patch

The enttec ODE is about as cheap as it's going to get besides rolling your own hardware. It's going to give you a female ethernet(artnet) to DMX converter, and you can input or output but not both at the same time with that one I think. It sounds like you'll just be sending, so it won't be an issue.

If that mixer is working, it may not be worth writing off so quickly though, depending on what the capabilities of it are.

dust's picture
Re: ARTNET patch

the mixer is a regular dmx operator type of thing. all the lights and what not are brand new out of the box so i know things are working.

the guy that was setting up the lights was having a hard time counting in increments of 16. i guess the lights have to be set to different numbers. so i think thats why they are messed up and don't work with the mixer right now. he was starting from 1....17...etc... i told him its easier to count in increments of 16 if you start at 0.

so im thinking thats the issue. i'm not really looking forward to climbing up to the ceiling and frigging with the lights but i suppose it will have to be done again.

gtoledo3's picture
Re: ARTNET patch

The lights likely have dip switches on the back to control what range they respond to, from the DMX being sent from the board. So if you're one index off, stuff can have some pretty funny results. This kind of functionality also allows you to intentionally group lights, etc. without them eating up your universe, if you just know that certain lights are always going to be working in unison.

If it was working, and nothing got changed cabling wise, maybe the board controls simply aren't mapped correctly anymore. I'm sure you'll have fun figuring it out either way ;)

At least the lights are already mounted!