The Dec 20 and Dec 28 betas wont respond to artnet
If I use V12.827.3539.0 Beta it works fine. The same setup with the more recent versions show no DMX levels.
All versions show they are running in FULL mode and I've configured them for the first two universes to use ARTnet.
On a related note... why does it want to start its universe at "1" forcing us to assign SLMEV Universe "1" to ARTnet Universa "0"?
I understand the feature to have any universe shown on any of the four "universes" available in SLMEV, but why use odd numbering schemes? Why not just call the SLMEV universes "displays" and label then "A", "B", "C", and "D". That way theres no confusion.
No Artnet since around V12.827.3539.0 Beta
Moderators: simonB, nick, RichterMC, florent, dylan, Ben
Re: No Artnet since around V12.827.3539.0 Beta
Please try art-net with the latest version and let me know if it is still not working properly
Simon
--
Sales/Support
--
Sales/Support
Re: No Artnet since around V12.827.3539.0 Beta
Thanks Simon, the Jan 10 2013 V13.110.4113.142 Beta build works with ARTnet.
I notice that the light beam control no longer dims the entire light and works as expected. It does seem much less intense than it was. I seem to remember it being solid when set to maximum at one time. I think it looks far more realistic now. My vote is to leave it alone, others may differ and prefer solid beams. Or.. It could be my custom fixture definitions
FEATURE REQUEST! (feel free to move to another thread if you wish)
One feature I am missing. is the ability to define separate dimmer channels for fixtures. I know its been mentioned a few times before, I also know its almost impossible without a total rewrite of the code.
Example Scenario:
At the theatre I work at, we have many Source 4's with Scrollers, iCue x-y mirrors and Iris's in various combinations and using various lenses (beam widths)
I've defined ssl's that mimic these combinations as a single intelligent fixtures and work well, but... in the real world...
Our huge ETC Dimmer rack uses dmx fron 513 up (2nd universe 1 and up) but the intelligent parts of the fixture use consecutive addresses in universe 1. This makes sense as we just plug in a fixture, add 512 to the circuit number we plugged it into and we have the dmx address for patching the board.
Typical Patch looks like this:
ION ch 1 (The ETC ION calls fixtures "channels" causing major confusion with dmx "channels", welcome to pro lighting)
dmx 121-124 iCue x-y mirror (16 bit mode)
dmx 125 Colour Scroller
dmx 126 Iris
dmx 536 Dimmer (second universe, dmx 24)
ION ch 2
dmx 127-130 iCue x-y mirror (16 bit mode)
dmx 131 Colour Scroller
dmx 132 Iris
dmx 1,25 Dimmer
and so on...
The SLMEV definition can only be:
1-2 X Pos
3-4 Y Pos
5 Colour presets
6 Iris
7 Dimmer
In order to work, every part of ever fixture on the entire ETC ION needs its patches changed. UGLY JOB!
If we do this and work off line with the ETC EOS/ION emulator (the whole point of having a visualizer), we MUST remember to selectively merge the resulting show and not LOAD it. If we load it, the patches come with it and every item on all three dmx universes we use goes insane all at once and cant be stopped until a sane patch is loaded. Can you imagine over 200 fixtures, fog, haze, snow machines, video systems, moving heads, etc, all out of control at once!
Its not only potentialy dangerous, but is extremely embarasing. and its all just because we loaded a show file just as we have done for years....
At first glance, this split, non sequential dmx addressing is a very difficult issue to fix, requiring a total change in how SLMEV is designed to work. It looks like it would, at the very least, require seperate addressing for every part of every fixture. In a perfect world, fixtures would be assembled out of sub-fixtures so that the iCue is defined seperate from the scroller, etc and yet the entire assembly would be expected to act as a single fixture for positioning and rendering.
Its easy to see that SLMEV just isnt written to deal with that.
Heres an idea that might work and at least help with the issue of conventional fixtures with intelligent add-ons.
Use a translation lookup table for addressing between the DMX stream coming from the hardware or ARTnet and the real SLMEV.
The idea is to seperate display from input.
the user would define a simple table something like this:
Real DMX = Display Address
121 = 0,1
122 = 0,2
123 = 0,3
124 = 0,4
125 = 0,5
126 = 0,6
536 = 0,7
127 = 0,8
128 = 0,9
129 = 0,10
130 = 0,11
131 = 0,12
132 = 0,13
1,25 = 0,14
Note the dual forms of denoting universe and address: 537 is the same as 1,25. There is no reason to make the user do this math. The lookup engine should be able to take either form and do the math itself.
What this achieves is that the board does NOT need to be repatched for use with SLMEV and SLMEV can now deal with split, non-sequential dmx addressing.
Fixture files for hybrid conventional fixtures with intelligent accessories are simply defined as a single intelligent fixture.
I have defined a set of combinations that work for our rig, i.e. Source 4 (dimmer) with iCue, Scroller, Iris, 19deg lens; S4 with iCue, Scroller, Iris, 50deg lens; S4 with Scroller and 26deg lens, and so on. These look like normal single fixtures, i.e. the ones with iCues are just intelligent moving heads to SLMEV.
Benefits:
If a patch is changed on the board, its trivial to change the lookup table, no need to redefine and/or reposition fixtures.
The show file generated by the off line board emulator is exactly what is loaded in the theatre. (no risk of loss of control).
SLMEV stg files can include the lookup but the lookup can be excluded from load into SLMEV if its not needed for some strange reason.
No changes to the rendering code required. Its a trivial, low risk code change.
No need to turn the lookup on/off, it can be left in place and default to 1-1
SLMEV can now be used with the REAL board for training or to match offline to reality and reality to off line.
An entire new market is opening for the product. For example. I would create a base stg file including the lookup for our theatre and recommend that the local community theatre groups purchase SLMEV so they can do their lighting design off line.
V2 could easily do a reverse lookup so the gui could display the "real" dmx addresses for the fixtures. Again, minimal risk code change as the rendering is not touched.
I havn't thought through V3, but maybe a stand alone program that could take in a csv patch definition file from the board, ask proper questions or have the user fill in the blanks and auto generate the lookup and assign fixtures. Kind of a semi-automated populate SLMEV with the fixtures so all we have to do is position them. Advancing on this, it just may be possible to have this "import" program deal with assembling ssl's from sub definitions. Once we tell it that the module ssl for the scroller is just the "colour" part of a big ssl and that the scroller is called "Scroller8b" in the board, it can easily plug that in as the colour part of a combined ssl when it sees its part of a channel from the boards patch file.
Comments?
Is there a reason why this wont work, or cant be done?
It may even be adapted as a stand alone product. I can think of occasions when it would be useful to use a netbook or something to take in ARTnet on one nic, run it through a lookup to change universes and addresses and put it back out another nic (or the same one running with dual IP addressing). I can see this being useful in merging two lighting rigs together, say the touring with the house, or just creating an easy to understand patch at the controller to a non sequential, chaotic reality. It would even allow the board to become sequential while the fixtures are not. reversing the situation we face now with SLMEV. Small netbooks are very cheap now and more than capable of this task with the addition of a usb ethernet port, or just use it as a wifi "hub".
I notice that the light beam control no longer dims the entire light and works as expected. It does seem much less intense than it was. I seem to remember it being solid when set to maximum at one time. I think it looks far more realistic now. My vote is to leave it alone, others may differ and prefer solid beams. Or.. It could be my custom fixture definitions
FEATURE REQUEST! (feel free to move to another thread if you wish)
One feature I am missing. is the ability to define separate dimmer channels for fixtures. I know its been mentioned a few times before, I also know its almost impossible without a total rewrite of the code.
Example Scenario:
At the theatre I work at, we have many Source 4's with Scrollers, iCue x-y mirrors and Iris's in various combinations and using various lenses (beam widths)
I've defined ssl's that mimic these combinations as a single intelligent fixtures and work well, but... in the real world...
Our huge ETC Dimmer rack uses dmx fron 513 up (2nd universe 1 and up) but the intelligent parts of the fixture use consecutive addresses in universe 1. This makes sense as we just plug in a fixture, add 512 to the circuit number we plugged it into and we have the dmx address for patching the board.
Typical Patch looks like this:
ION ch 1 (The ETC ION calls fixtures "channels" causing major confusion with dmx "channels", welcome to pro lighting)
dmx 121-124 iCue x-y mirror (16 bit mode)
dmx 125 Colour Scroller
dmx 126 Iris
dmx 536 Dimmer (second universe, dmx 24)
ION ch 2
dmx 127-130 iCue x-y mirror (16 bit mode)
dmx 131 Colour Scroller
dmx 132 Iris
dmx 1,25 Dimmer
and so on...
The SLMEV definition can only be:
1-2 X Pos
3-4 Y Pos
5 Colour presets
6 Iris
7 Dimmer
In order to work, every part of ever fixture on the entire ETC ION needs its patches changed. UGLY JOB!
If we do this and work off line with the ETC EOS/ION emulator (the whole point of having a visualizer), we MUST remember to selectively merge the resulting show and not LOAD it. If we load it, the patches come with it and every item on all three dmx universes we use goes insane all at once and cant be stopped until a sane patch is loaded. Can you imagine over 200 fixtures, fog, haze, snow machines, video systems, moving heads, etc, all out of control at once!
Its not only potentialy dangerous, but is extremely embarasing. and its all just because we loaded a show file just as we have done for years....
At first glance, this split, non sequential dmx addressing is a very difficult issue to fix, requiring a total change in how SLMEV is designed to work. It looks like it would, at the very least, require seperate addressing for every part of every fixture. In a perfect world, fixtures would be assembled out of sub-fixtures so that the iCue is defined seperate from the scroller, etc and yet the entire assembly would be expected to act as a single fixture for positioning and rendering.
Its easy to see that SLMEV just isnt written to deal with that.
Heres an idea that might work and at least help with the issue of conventional fixtures with intelligent add-ons.
Use a translation lookup table for addressing between the DMX stream coming from the hardware or ARTnet and the real SLMEV.
The idea is to seperate display from input.
the user would define a simple table something like this:
Real DMX = Display Address
121 = 0,1
122 = 0,2
123 = 0,3
124 = 0,4
125 = 0,5
126 = 0,6
536 = 0,7
127 = 0,8
128 = 0,9
129 = 0,10
130 = 0,11
131 = 0,12
132 = 0,13
1,25 = 0,14
Note the dual forms of denoting universe and address: 537 is the same as 1,25. There is no reason to make the user do this math. The lookup engine should be able to take either form and do the math itself.
What this achieves is that the board does NOT need to be repatched for use with SLMEV and SLMEV can now deal with split, non-sequential dmx addressing.
Fixture files for hybrid conventional fixtures with intelligent accessories are simply defined as a single intelligent fixture.
I have defined a set of combinations that work for our rig, i.e. Source 4 (dimmer) with iCue, Scroller, Iris, 19deg lens; S4 with iCue, Scroller, Iris, 50deg lens; S4 with Scroller and 26deg lens, and so on. These look like normal single fixtures, i.e. the ones with iCues are just intelligent moving heads to SLMEV.
Benefits:
If a patch is changed on the board, its trivial to change the lookup table, no need to redefine and/or reposition fixtures.
The show file generated by the off line board emulator is exactly what is loaded in the theatre. (no risk of loss of control).
SLMEV stg files can include the lookup but the lookup can be excluded from load into SLMEV if its not needed for some strange reason.
No changes to the rendering code required. Its a trivial, low risk code change.
No need to turn the lookup on/off, it can be left in place and default to 1-1
SLMEV can now be used with the REAL board for training or to match offline to reality and reality to off line.
An entire new market is opening for the product. For example. I would create a base stg file including the lookup for our theatre and recommend that the local community theatre groups purchase SLMEV so they can do their lighting design off line.
V2 could easily do a reverse lookup so the gui could display the "real" dmx addresses for the fixtures. Again, minimal risk code change as the rendering is not touched.
I havn't thought through V3, but maybe a stand alone program that could take in a csv patch definition file from the board, ask proper questions or have the user fill in the blanks and auto generate the lookup and assign fixtures. Kind of a semi-automated populate SLMEV with the fixtures so all we have to do is position them. Advancing on this, it just may be possible to have this "import" program deal with assembling ssl's from sub definitions. Once we tell it that the module ssl for the scroller is just the "colour" part of a big ssl and that the scroller is called "Scroller8b" in the board, it can easily plug that in as the colour part of a combined ssl when it sees its part of a channel from the boards patch file.
Comments?
Is there a reason why this wont work, or cant be done?
It may even be adapted as a stand alone product. I can think of occasions when it would be useful to use a netbook or something to take in ARTnet on one nic, run it through a lookup to change universes and addresses and put it back out another nic (or the same one running with dual IP addressing). I can see this being useful in merging two lighting rigs together, say the touring with the house, or just creating an easy to understand patch at the controller to a non sequential, chaotic reality. It would even allow the board to become sequential while the fixtures are not. reversing the situation we face now with SLMEV. Small netbooks are very cheap now and more than capable of this task with the addition of a usb ethernet port, or just use it as a wifi "hub".
Re: No Artnet since around V12.827.3539.0 Beta
Hello, your post is too long. Please make it shorter. I have a lot of other customers!
Simon
--
Sales/Support
--
Sales/Support
Re: No Artnet since around V12.827.3539.0 Beta
Well.....
That's customer service!!!
I offer a simple idea that will solve many feature issues with the product, describe what it is, what it will do and what issues it will solve, even the basic sof how to implement it, as well as what features it would add, and that it even has the potential of adding a revenue generating product to the line and I get....
"I'm too busy, make it shorter...."
Glad to see that Nicolaudie hasn't changed... Still arrogant, rude, patronizing, ignoring customers and producing inferior bug ridden product.
Go play in the DJ market, your not ready to play with the big boys, and never will be with this attitude. Ever wonder why you have virtually no market share in North America?
Loose the attitude!
Even a simple pm saying could you give us a simple overview would have been better than the "I'm too busy to pay attention to you" attitude.
It's all in how you present and phrase things and this was done very badly indeed.
That's customer service!!!
I offer a simple idea that will solve many feature issues with the product, describe what it is, what it will do and what issues it will solve, even the basic sof how to implement it, as well as what features it would add, and that it even has the potential of adding a revenue generating product to the line and I get....
"I'm too busy, make it shorter...."
Glad to see that Nicolaudie hasn't changed... Still arrogant, rude, patronizing, ignoring customers and producing inferior bug ridden product.
Go play in the DJ market, your not ready to play with the big boys, and never will be with this attitude. Ever wonder why you have virtually no market share in North America?
Loose the attitude!
Even a simple pm saying could you give us a simple overview would have been better than the "I'm too busy to pay attention to you" attitude.
It's all in how you present and phrase things and this was done very badly indeed.