Art-Net Externals - V1.0 Beta - 64-bit and Multiple Universes
Finally had the time to finish the updated version of my Art-Net externals. Both objects have been totally re-written, now using an plugin-focused Art-Net library which I've been developing for a while.
New Features
- 64-bit and 32-bit versions (compatible with Max 6 and 7, OS X and Windows)
- The objects can now send and receive multiple universes at once. This means you only need one object to send/receive any number of contiguous universes of data.
- All objects now reference a single Art-Net service object behind the scenes, which means you can create multiple imp.artnet.node objects without getting a port binding error.
- A variety of more flexible output modes are now available for both objects.
- imp.artnet.controller is no longer hard-limited to send at maximum 44 FPS, so if you want to send data faster you can manually drive it with a metro at higher speeds.
Known Issues
- The sync_universes attribute on imp.artnet.controller has not been implemented yet. Sending universes will currently always be synced.
- Performance on imp.artnet.controller is due to be improved by reducing redundant copying, but this isn't in this build. Shouldn't be noticeable unless you're using a stupid number of universes though.
Download link below. Please report any bugs in this forum thread.
Great! Thanks for sharing!
Wow, that's great news. Thanks, David, amazing work.
Awesome!
I'm getting these error messages when trying to load the externals though (32bit Max7 on Mac):
imp.artnet.controller: unable to load object bundle executable
2015-03-16 21:11:55.134 Max[19176:11746285] Error loading /Users/Rodrigo/Documents/Max 7/Library/imp.artnetV1_0Beta/imp.artnet.controller.mxo/Contents/MacOS/imp.artnet.controller: dlopen(/Users/Rodrigo/Documents/Max 7/Library/imp.artnetV1_0Beta/imp.artne
t.controller.mxo/Contents/MacOS/imp.artnet.controller, 262): Library not loaded: /opt/local/lib/libboost_system-mt.dylib
Referenced from: /Users/Rodrigo/Documents/Max 7/Library/imp.artnetV1_0Beta/imp.artnet.controller.mxo/Contents/MacOS/imp.artnet.controller
Reason: image not found
imp.artnet.node: unable to load object bundle executable
2015-03-16 21:12:01.529 Max[19176:11746285] Error loading /Users/Rodrigo/Documents/Max 7/Library/imp.artnetV1_0Beta/imp.artnet.node.mxo/Contents/MacOS/imp.artnet.node: dlopen(/Users/Rodrigo/Documents/Max 7/Library/imp.artnetV1_0Beta/imp.artnet.node.mxo/C
ontents/MacOS/imp.artnet.node, 262): Library not loaded: /opt/local/lib/libboost_system-mt.dylib
Referenced from: /Users/Rodrigo/Documents/Max 7/Library/imp.artnetV1_0Beta/imp.artnet.node.mxo/Contents/MacOS/imp.artnet.node
Reason: image not found
Ok, looks like XCode linked the bundle to the dynamic boost library rather than the static version. Will get a new build up in a bit.
OK new build is up at the same link, can you try and let me know?
Yup, loading fine!
This is great. Means sigmund~ is my only remaining 32bit external.
Thats great! thanks!
I am getting this error in win7 and MAX 5:
The procedure entry point gensym_tr could not be located in the dynamic link library MaxAPI.dll
I have also a question about art-net objects not sure if is the right post to do that:
I want to send 4 DMX universes in madrix luna 16 via ethernet
I am using
imp.artnet.controller @auto 1 @unicast 1 @unicast_ip 127.0.0.1 @universe 1
imp.artnet.controller @auto 1 @unicast 1 @unicast_ip 127.0.0.1 @universe 2
imp.artnet.controller @auto 1 @unicast 1 @unicast_ip 127.0.0.1 @universe 3
imp.artnet.controller @auto 1 @unicast 1 @unicast_ip 127.0.0.1 @universe 4
is this the correct object to do that? and is the @unicast_ip the IP address of madrix LUNA
thank you very much
The new objects don't support Max 5 unfortunately, they're built with the Max 6 SDK.
If you're using the old version of the objects then yes, that is the correct way to send four universes, and @unicast_ip is the ip address of the target fixture.
If you're using the new version though, you only need one imp.artnet.controller object to send all four universes, just set @num_universes to 4, and send your data as a 2048 item list.
David, I just tested the controller object on Max 7 and it doesn't seem to work with @unicast 0. I have a DMXKing device that works fine with the previous version (imp.dmx.artnetout) on Max 6, but I couldn't get it to work with the new object. By the way, I haven't tested it with unicast on because I was outside my house and didn't knew the device's ip address (oops)...
I will check this out when I get a chance. What happens exactly? Any errors or just no data coming through the other end?
No errors, but no data on the other end. I thought it had something to do with my network configuration, but, as I said, I'm using broadcast mode in Max 6 with the older objects and it works just fine. I will make some more tests today and I will let you know.
David, I have made another test, but I still couldn't get it to work. I found my device's ip number and I used your object with the correct @unicast_ip attribute. One of the lights of my artnet device started blinking, indicating network activity, but it still doesn't receive any data (the light which indicates received data is always off). Maybe I'm doing something wrong?
(I'm using a DMX King's eDMX1 with an 2.x.x.x ip)
I have the same problem,
Works fine with 0.5 but with 1.0 my controller doesn't receive anything, using the exact same settings.
@Nat, is this problem only in broadcast mode?
Hello,
I tried both broadcast and unicast with no success...
Same thing here. My device detected network activity in unicast mode, but didn't received anything. In broadcast no activity was detected.
The device I use is a custom made Arduino so I'll try to print the full UDP packet tonight to see what's going on...
I just tested using netcat and I can't seem to receive anything from the new version.
What's your network configuration Nat?
I tried at home and at work.
At home my device has IP 192.168.2.2 and my computer has IP 192.168.2.1
Using that config the older object works fine as well as my other Artnet programs (Vezér and PixelController) but the new object doesn't seem to send anything.
At work I tried using netcat to check udp traffic on localhost. Using the udpsend object I could see the data using netcat but the artnet external doesn't seem to send anything either...
Presumably your sub-net mask at home is 255.255.0.0? I only ask because the normal for home networks is usually 255.255.255.0.
It's at 255.255.255.0 now but I think I tried both although I'm not 100% confident. I can try again tonight with 255.255.0.0
Leave your sub-net as it as and change your device addresses to use the same network prefix (192.168.1 or 192.168.2)
Oops actually there are on the same prefix, it was a typo:
Computer: 192.168.2.1
Artnet device: 192.168.2.2
HELP!!!! trying to send artnet out of ableton to madrix via artnet on a internal loopback adapter. my network says its sending packs to the network but not recieving it in madrix. tested madrix and its recieving data from other devices.so the problem is from ableton/max for live. any way to send streaming acn that would be better. just trying to get this to work please help!!!
I suggest you use the Art-Net externals included in imp.dmx as they are more stable releases. This update is still a beta and has issues, it shouldn't really be used for any shows.
There's no objects that I know of that support sACN, however the only advantage it gives over Art-Net is that it can send data via multicast, which doesn't apply to your situation so Art-Net will work fine.
how do i setup the externals to work?
Look up 'search path' in Max help. You need to add the entire folder containing all imp.dmx files to the Max search path.
Just tested with my hardware setup and the 1.0 isn't working with my DMXking interface. No error messages or anything, it's just not sending anything.
I was using '@auto 1' in the old version of my patch and the 1.0 flags that as an error, so I removed it, but the 1.0 doesn't seem to work, don't know if it has to do with that.
This is the core send section of my patch:
Hmm, there's definitely some deeper issue here. I will investigate further.
@auto has been removed and replaced with @mode as there are now multiple types of input/output functionality, one of which is auto. See the help patcher for more details.
Also @unicast is now true by default, as sending data via unicast is far more common now than sending broadcast (which is @unicast 0).
I had a look at the help file but it didn't look massively different from the old one, and all of the @attributes I had set in a 'set it and forget it' kind of method. Meaning I had forgotten why everything was set up the way it was.
So "@auto 1" = "@mode auto"?
@auto 1 = @mode 3, but that's the default anyway. In 'Automatic' mode, the frequency of Art-Net packets being sent is handled for you. This mode is actually the one defined in the Art-Net specification, in that updates are sent at up to 44 Hz whenever that data is changing. If data is not changing, the current data set is sent at 0.25 Hz.
The above mode of operation is the most sensible in most scenarios, however, it means that if a device is disconnected and then reconnected, it could take up to 4 seconds to re-sync to the current data. Therefore some devices just send at a constant frame-rate, which you can do by setting @mode 4, 'Forced Framerate'. There's additional a frame-rate attribute to configure this.
You can also choose to send packets every time a data message is sent to the object but never if data is static (@mode 1 'On Update Only'), every time the data actually changes (@mode 2 'On Change Only'), or only ever when a bang is sent to the object (@mode 0 'On Bang Only'). This last method allows you to drive the object from a metro or qmetro, which helps you to integrate it easily into an existing Jitter patch and ensure that you link Art-Net packet generation to your Jitter frame updates. This is also the only method which isn't limited to send at a maximum of 44 Hz, so you can also use this method to drive at faster update rates (which can be useful for pixel mapping).
Ah yeah, assuming everything else is the same, the 1.0 should work the same as 0.8 (with @auto 1)?
It should yeah, just leave all the attributes at their defaults for trouble-free operation. The only thing you'll have to set is the unicast ip.
David, today I made some more tests. My device is a DMXKing eDMX1 and I decided to try different IP numbers. It was in the 2.x.x.x range, but I changed it to 10.x.x.x and later to 192.x.x.x. Unfortunately I got the same results in every test: in broadcast mode nothing happens. In unicast mode the device detects network traffic, but doesn't receive any data. I also tried all modes.
I thought it could be a network configuration issue, but broadcast and unicast mode worked perfectly with the 3 different IP addresses in Max 6 with [imp.artnet.controller].
If you like, I could run some other tests. Hope this information is useful somehow.
OK, there's definitely some major issue with the network system. I can't get anything out of the current build at all. Wireshark monitors show no packets being sent, yet strangely the send function isn't reporting any problems. Will investigate further and get a new build up soonish.
Hi David, just tested out your latest 64-bit imp.artnet.controller external with my eDMX1. According to Wireshark, the external is sending UDP packets with a size of 1066 bytes (instead of the expected 572 bytes). It looks like there is extra data being appended to the end of a normal Art-Net packet. Also tried changing the num_channels attribute, which changes the amount of DMX data within the packet, but it is still appends extra data to the packet (fills) until it reaches a size of 1066 bytes. Just thought I would pass this info along to help out. Keep up the good work man, you rock! Cheers!
New build is up at the same link. The packet length should now be correct, thanks to Troy for spotting that. I've also fixed broadcast mode, please re-test.
Thanks to all for your help so far.
David, I couldn't get the new build to work. The object cannot be loaded. This is the error message:
imp.artnet.controller: unable to load object bundle executable
2015-05-03 14:46:04.023 Max[528:17116] Error loading /Users/matheusleston/Documents/Max 7/Library/imp/imp.artnet.controller.mxo/Contents/MacOS/imp.artnet.controller: dlopen(/Users/matheusleston/Documents/Max 7/Library/imp/imp.artnet.controller.mxo/Conten
ts/MacOS/imp.artnet.controller, 262): Library not loaded: /opt/local/lib/libboost_system-mt.dylib
Referenced from: /Users/matheusleston/Documents/Max 7/Library/imp/imp.artnet.controller.mxo/Contents/MacOS/imp.artnet.controller
Reason: image not found
FFS. Xcode is really shitty with dynamic/static library linking. I'm explicitly including the static boost library and yet it still insists on linking to the dynamic version if it even exists in the same directory.
New build is up at same location.
David, I'm glad to say that now it seems to work perfectly fine. Just tested it in unicast and broadcast mode and both worked on the first attempt. I will now test it with two devices with different IP addresses and I will let you know.
Thank you for the amazing work!
Great news! Out of interest are you running in Max 6 or 7? In the last build I've updated to use the new Max 7.0.3 SDK and haven't tested the compatibility yet...
I'm using Max 7, but I will soon test it on Max 6.
Btw, I was trying to use two DMX interfaces with two different Thunderbolt connections, but I can only get one to work. Is there any solution or should I use a hub?
I haven't really addressed the issue of multiple network adapters in the code yet. It's on my list for the next update, where you'll be able to select which network adapters to use as an attribute.
Oh, that's great, looking forward for it. For now, I will work with a hub. Thanks again!
David, I just made some basic tests with the new objects in Max 6 via Max For Live (with Ableton Live 9 running in 64bits mode) and it worked perfectly fine. Amazing stuff.
Just one question: how does it decide which network to use? I'm running a system now with two independent ethernet connections, one for the artnet interface and the other for midi sync with another computer. It seems that sometimes it uses the right network, sometimes the other one (and the lights don't run, of course). Is there anyway to guarantee it will use the right one?
Hi David,
Using imp.artnet.controller, if you set a num_channels over 512, then it will output artnet over multiple universes but not on consecutive universes, they will be offset by 512 universes from each other. I'm not sure if its intentional or not, but feel like the universes should be consecutive.
Thanks for your amazing externals!
Thanks for spotting that Hugobox, I'll take a look and get a new build up shortly.
The universe increment issue has been fixed. New builds up at the same link.
Hi David,
I think the abstraction imp.dmx.read.maxpat has the first route wrong.
I think it is supposed to be "route prefix matrix" instead of "route matrix prefix".
Is that correct?
Thanks!
Yup, those are the wrong way round. Thanks for spotting that. Will change and re-upload later.
Hi David,
Another little thing i noticed with the "imp.artnet.controller @unicast 1 @mode 4" is that after you disable it "enabled 0" and then re-enable it "enabled 1" it doesn't restart outputtinglike expected. Mode 4 has to be resent in order to re-activate the output. No big deal since its an easy fix but thought I'd throw it out there.
Good day!
Hi David and all,
I tried using your externals, but max immediately crashes when I create the objects.
I'm using max7 64 bit on windows 7, and I used the objects from this link : https://dl.dropboxusercontent.com/u/6111626/imp.artnetV1_0Beta.zip
Has anyone had such issue?
Thanks
Hi David and all,
I know this thread is old but it seems better than start a new one. I have been using imp.artnet 0.8 without problem (very useful object by the way), and I am now trying to update to the v1.0Beta since I am using Max7, and wanted to work on 64bits.
What happens is that the CPU of my Mac goes above 100% cpu when opening any patch with the imp.artnet object (even the help patch). Is anyone else experiencing this ?
I am on Yosemite on a macbook pro retina.
Thanks
Alain
Alain, I'm also on Yosemite and with a Retina MacBook. Everything is working pretty well here with imp v1.0!
Thanks Matheus for the feedback !
I will do some further search on where the problem lies is in my setup...
@alain I will check and see if I can reproduce this behavior.
@David I made some more tests and I can reproduce the same behaviour on my other setup, osx 10.9.5 and Max 7.0.3 (my main system is max 7.1.0 and osx 10.10.4)
in both setups, as soon as I create the imp.artnet.controller object, the Max's CPU usage goes above 100% (in the activity monitor).
I tried to use @mode 0 to see if it changed anything but it stays the same (for any mode).
hth
Hi all,
I'm working on a complex setup using the imp externals but as Alain says also my Max's cpu usage goes above 100% (170% and sometimes 200%) when using the imp.artnet.controller (monitored through activity monitor).
I'm not experiencing any crashes but I think that there is something strange in this behavior.
I'm using a MBPro retina with Yosemite 10.10.5 and Max 7.1.0 in 32/64 bit mode but the same thing happen on a friend's computer with Maverick and Max 7.1 installed.
Thank you all for the help and in particular to David for the awesome externals.
@David
There are some news regarding the cpu problems mentioned above?
Thank you!
@Pjeve Will have some news soon. Stay tuned.
Hi David ,
first , thanks a lot , lot , for this external, as i just need it , just now :)
I need your advice David,
i'm planning to build a quite big videowall, using RGB pixels (spi connection) ,
and a artnet to spi controller called the BC-216, that can be bought in china...
In fact, i'll use two of them , and will send 20 universes , in order to control 20 SPI connections.
I won't exceed the 512 channels , in any universe.
Do you think that your external will be able to carry these 20 universes ,
all together,
and that i shouldn't have any problem, as i want to refresh the pixels 30 times per second ?
here is the controller i'm intending to use :
https://fr.aliexpress.com/store/product/BC-216-Artnet-to-SPI-DMX-pixel-light-controller-Eternet-protocol-input-340pixels-16CH-two-ports/701799_32648000521.html?spm=2114.12010612.0.0.QVlGSz
I think it should be OK, as 20 universes of DMX , through an ethernet connexion ,
seems soooo light ...
but who knows , i'm maybe missing something important .
Thanks a lot , again ,
Matthieu
yeah,
3 useless posts in a row !
in 1st post of this thread is the answer.
20 universes is not a stupid number of universes,
so yes, it'll work.
:)
I've got 4 universes of 160 channels each.
So i made a message of 640 length and change the channels in the artnet.controller .
But it change the amount of universe to 2, when in fact i've got 4 universes.
Is there a way to have 4 universe and 640 channels ?
Nevermind, if i use my 2cents i see that what i'm saying is dumb.
But, i still got a problem.
In fact, i've got 4 universes and 480 channels for each universe.
However i can't get my mapping right.
I have 20 strips of 32 leds, but my matrix have to be 20 by 96 to have something that look like what i'm sending.
I don't know what i'm doing wrong.
Nobody's got an idea ?
I tried with the version 0.5 and multiple matrix for each of my universe but my mapping is still wrong.
If you want to send multiple universes, you have to send full universes of 512 channels. Pad each universe out with zeros, so that your list length is 2048 for 4 universes.
Ok so basically i just have to add some 0 to my list with a coll or do i have to add 2 channels 0 to each value of my list ?
When you send a list into the object, the values you send it set the channel values according to their position in the list. So the first value sets channel 1, second value sets channel 2, etc. When you're sending multiple universes, you can think of universe 2 channel 1 as being channel 513. So you need to add values of zero to list positions 481-512 in order to complete the universe and access channel 1 of universe 2.
Well, I got used with working with several instances of imp.artnet, one for each universe. I'm not quite sure if it is really bad practice (is it, David?!) but it works like a charm.
BTW, David, a long time ago you talked about the possibility of using different networks with your objects. Any news about that?
Ok i thought that your object imp.dmx.read complete the list automatically, my bad.
So if i understand, i have for each value in my matrix 2 others to have a list of 512. Because the list i get from the matrix got one value per pixel and not 3 like needed to fill the channel. Is that right ?
Or i just need to fill up 170 value who will be indexed before going to the object ?
I'm sorry, i confuse myself with data and channels
I figure how to make my 512 list for my universe but i've still got issue.
The mapping isn't still right.
I have attached the method that i use if the problem come from it.
I'm sorry to bother all of you again, but despit my effort i still don't have the result i expect.
I format my data to have to message of 1024 to send at @ universe but i doesn't work.
I use a pixlite for the led but i don't that is the source of the problem.
If someone could give me a hand that would be really great.
I finally manage to understand how my mapping work.
I'm so sorry for the spam.
I would like to thanks david for the explanation that lead me to the solution.
Finally got around to testing this more thoroughly.
The v1.0 version of imp.artnet.controller is costing over double the cpu that the v0.8 is. This is on OSX 10.12.5 on 32bit Max (7.3.4).
The device in question is [imp.artnet.controller @unicast 1 @unicast_ip 169.254.0.1] and CPU on my patch (in activity monitor) goes up to 187% with the new version and 89% with the old version.
Rodrigo, I think this is a well known issue. David talked about it in this topic: https://cycling74.com/forums/imp-dmx-imp-artnet-controller-cpu-usage-insanely-high
I can confirm that watching Activity Monitor with those objects is something pretty scary, but I have to say that I never had any issues. I'm using imp.arnet for almost every project I do and some of them are really heavy on processing (live visuals, audio processing, mapping and so on) and those objects doesn't seem to impact the computer's performance at all.
Interesting, I'll give it a spin in context to see if it freaks out.
Ok, tested, and it's not playing nice. CPU is over 210% using the v1.0 (vs 95% on v0.8) but more importantly, the Max schedule starts acting weird (connecting/moving cables not rendering correctly, print not working, display via [message] right inlet) and the DMX packets kind of dropping or something. Something that shows up as a smooth gradient starts acting choppy and binary.
(the weird scheduler stuff is something I've noticed before when the CPU goes through the roof, that the 'Max' side of Max gets backlogged and doesn't work for a while)
Rodrigo, that's really something worth investigating, as my experience is completely different. As I said, I'm running several instances of the object for different universes (usually 9) in a live situation with audio analysis to control light fixtures and never had any issues of lagging or strange behaviour caused by imp.artnet. Could you share your patch and your computer specs?
Hi,
amazing work!!! I'm really interested in using it, can I use this object with any Art-Net device? I'm thinking right now in buying a dmxKing or ENTTEC, any recommendations? Also saw a Chauvet interface with Art-Net. I'm running Sierra 10.12.6 with Max 7,
thanks in advance,
best!
@Rodrigo, I couldn't understand your patch! Can you point out where the object is? If you like, tell me what you want me to test I can I run it here. Just a note, I guess my main Max computer was, until last month, the exact same as yours. Curious.
@Agustin Yes, it should work fine with any art net interface, you just need to check your network configuration, as it might change (different art net interfaces work in different ip ranges). I have one DMX King and two Show Jockey, they all work perfectly fine.
@Matheus
Hehe, yeah it's a bit of a mess that one...
Just a quick/hacky prototyping type patch.
On a positive note I think I may have found what was overrunning my scheduler. I was inadvertently (due to lack of [change]) reading and starting a [mtr] object over and over with every onset that was being detected. That seemed to back things up.
Still getting much higher CPU from the v1.0 version, but I'll give it another test once I've finished with the upcoming gigs I have (what I have now "works", so I don't wanna rock that boat)
@Agustin
I have a DMX King interface that I'm quite happy with.
@David Butler
Hi David, Thanks for sharing Art-Net externals .
Do you ave a plan to integrate ArtSync into imp.artnet.controller?
@David Butler
Hi David,
The download page is down - would it be possible to upload the latest version? Is it up to date with the latest version of Max and Mac OS?
And my main question: if you had to answer objectively, what would you say is the most reliable, cpu efficient and low-latency way to control / trigger lights real-time? Is there a particular hardware solution you would prefer (Enttec, LanBox, self-programmed Teensy/Bela etc.), a script or protocol you would recommend over the other? Is it perhaps better to route OSC/midi between applications, and deal with the lights outside of Max? I have noticed that you, in some of your externals, write "DON'T USE IN PERFORMANCE", so that's why I ask.
I recently used Enttec USB Pro with Olaf Matthes' externals in a contemporary theatre / music piece that I wrote for viola & live electronics, with interactive / live-controlled lights. Onset detection and an envelope-follower controlled the various dimmers, a spectral centroid-calculation (in [gen~]) controlled various pan-, tilt- and zoom-functions, and I manually adjusted responsivity, color-scenes and thresholds throughout the piece. It worked well and the latency was relatively low, but I do not trust the externals 100% because they are made with an old version of Max on an even older OS.
Considering the LanBox LCX, and was hoping that your external could do the trick. I need something that I can use for concert premieres, where the stakes are super high, something that just simply works, and I would love to hear what you guys have to say before I choose what to buy and use.
Best,
Martin
https://www.dropbox.com/s/fifxtr2q146kino/imp.artnetV1_0Beta.zip?dl=0
Not sure why the previous link expired!
The 'DON'T USE IN PERFORMANCE' warning is just because this release was a beta and I hadn't tested it extensively. After 3 years now, I've had a lot of bug reports about high reported CPU usage in task manager, however this doesn't seem to relate to a real-world performance drop. I had basically abandoned this external for now because I had a much more comprehensive Max DMX system in the the pipeline, but it's been a few years now and finding time to work on this with my schedule is proving very difficult as invariably I have at least 3 development projects on the go at any one time... My short-term plan is just fix this bug and release a non-beta version of the above externals as a stop-gap until I can finally get my other system ready.
Using an IP protocol like Art-Net or sACN is definitely the best way to go, as it gives you maximum flexibility on hardware. It's also the best performance solution as you can get.
I don't like the LanBox because it it's DMX output rate is only 20 Hz, whereas most DMX devices output at 44 Hz (although a lot of pro level consoles use 30 Hz). Something like the Enttec ODE is a far better Art-Net to DMX product.
@David Butler, really curious about this new DMX system! Could you share a bit more about it?
Indeed the CPU bug is quite strange, as it really doesn't affect performance at all, as far as I can tell. I have being using those objects for quite a while in really critical moments and they work absolutely great.
So the thing I've been developing for ages is a complete DMX system called LXMax, designed to bring DMX support for Max as a first-class protocol in a similar way to MIDI.
You don't have to understand how to format all the bytes in a MIDI message in order to just send note on messages in Max, so therefore you shouldn't have to implement a massive system in every single patch to format a DMX packet and send it.
In LXMax, you get an global settings window (accessible via the Extras menu) where you can configure your outputs and what hardware/protocol you are using (aiming to support Art-Net, sACN (E1.31) and Enttec DMXUSBPro to start with), and then you create objects in your patch which connect to this. All channel mixing, merging etc is all done behind the scenes in a dedicated global service which runs in the background constantly.
LXMax provides objects which directly represent the actual lighting fixtures you work with rather than representing DMX data. The main ones are:
lx.dimmer - controls 1+ channels of simple dimming control.
lx.colorfixture - controls a fixture with color and dimming (LED Parcans mainly)
lx.fixture - controls a complex fixture by loading a personality file.
Advantages of this over current workflow:
You never have to worry about formatting massive long lists of 8-bit channel values. In fact the actual DMX values are completely opaque to the patch.
You can work with numbers and ranges that make sense rather than everything having to be transformed to an 8-bit range.
You can design your patch without knowing what DMX hardware/protocol you're going to use. Also you can change hardware/protocol without changing your patch, as simply as if you were changing to a different audio interface. You can also use different interfaces at the same time and send them the same/different data.
You can open multiple patches using DMX simultaneously and the service will automatically merge the data (based on an LXMax object merging properties).
Obviously this is quite a big development project and I've been working on it (on and off) for about 2 years now. Can't really give any reliable estimate about when it will be ready as it's entirely dependent on my commercial development schedule but I'll be posting news here when I have something to share.
That sounda fantastic!
I really look forward to it coming along.
Wow, really amazing stuff. The ability to load personality files changes everything! Looking forward to it.
I'm not much of a programmer outside the realms of Max, but if there is something I could help you with, I'm available!
Thank you for the link update and for your reply, David.
I took your advice and have just ordered an Enttec ODE, so I am looking forward to learning the protocol properly and to test how hard I can push this setup (mainly worked with Enttec USB Pro). Was not aware that en LCX had a fixed hertz, thanks for the heads up.
Also, LXMax sounds exactly like what I have been looking / hoping for. Are you coding in C++? And when you say that "the actual DMX values are completely opaque to the patch" - does that mean that the lx.fixture (with a loaded personality file) will "understand" e.g. coarse+fine 16bit-controls, so that users don't need to do stuff like this: https://youtu.be/cJl0TtbBQvc ?
Looking forward to hearing about the progress, and I hope you get some help with all of this work. Let me know if you need help testing / debugging betas etc.
Best,
Martin
Yes, all coded in C++. Unfortunately cannot be an open source development as the core DMX library it uses is shared with one of my commercial developments. However will definitely be free to use.
You're correct on the 16-bit values. Essentially the personality file defines what attributes the object should have, what their sensible ranges are (so a range in degrees for pan/tilt, or an on/off control for an effect function) and how those ranges map to DMX channels. Also allows the object to display fixture colour as a proper Max colour attribute, etc. It's an experience much more like using a proper lighting console.
Amazing stuff as usual, David! Looking forward to it. As I said, let me (us, actually) know if you need any help!
hi david, great work!
but when i use more then 3 universes in obj: imp.artnet.controller @mode 4 @unicast_ip 127.0.0.1 @num_universes 6....Arrive only 3 universes.
any suggest?
thx
David, I just found something that might help with your investigation of the high CPU usage: although it really doesn't seems to affect performance (I've been using it for years with no noticeable issues), it does seems to affect energy consumption.
I have a 2017 15" Macbook Pro (the touchbar one) and as far as I can tell it is pretty well known that it has a lot of issues regarding power consumption and charging. I moved a big project from my old computer to this one which involves a huge Ableton Live session, Resolume Avenue 6 and your object is inside a very simple Max For Live device. With everything running and with the computer plugged in charging, the battery level starts to drop quite slowly. Of course it has to do with the high usage, but looking at the Activity Monitor it shows that Ableton is using about 120% of the energy. When I delete the M4L device with your object, it drops to about 40% and the computer start charging again, although really slowly. I tried using it outside Ableton, with a Max patch, and the Activity Monitor shows it as using 99% of the energy.
I really don't know if this will help you in any way, but I hope it does. Let me know if you need more testing.
Digging up an old thread.
@MATHEUS LESTON
when you say you got it to work, was is with your dmx king node ??
I got the beta V1 to work with an entec usb and with an AN6U1903 . But can't get it to work with a eDMX4 DIN <--dmx king.
Can any of you who got this to work care to share the steps.
I tried with both the older version 0.5 from here https://www.theimpersonalstereo.com/impdmx/
although when you open it open in max7 32bit windows
it says V1.00 beside the logo
and the beta version from https://www.dropbox.com/s/fifxtr2q146kino/imp.artnetV1_0Beta.zip?dl=0
here tried in Max 7 and Max8 64 bit mode.
No go.
thanks for the help guys
phiol
No, I don't have this device anymore, but it worked pretty well for me. I have other Art-net interfaces now.
For me it was always quite simple: set the IP, computer in the same range, no other networks on (just in case), done. I'm using the latest version, available in the Impersonal Stereo website.
was it the dmx king ??