DMX errors and Effects
-
- Posts: 211
- Joined: Sat Jun 01, 2013 8:23 am
- Location: Adelaide, Australia
DMX errors and Effects
Hi there,
I used extensive effects recently, and I did notice a few peculiarities: in frequent intervals, the 2x LSC ePro dimmers that were connected via the EnTTec USB DMX Pro mk2 reported DMX errors and then reacted erratically and sluggish (with channels that were not part of the chase coming up briefly, and the chase not playing in real time), and although starting and ending the chases I used via the EFXstart and EFXstop command, with "Clear effect on stop" ticked, sometimes levels seem to persist in live (some of which I was able to get rid off after running other effects, and others only disappearing after a restart of the software).
The effects used overriding times of 0 fade up and 0 fade down and 0.25 follow. Is there anything that could conceivably cause these DMX errors in the software? Or in the hardware?
Finally, I once again would have loved a way to influence the playback speed of an effect via command line and/or OSC/MIDI... working like a multiplier on all times used by an effect, i.e. the cue fade and follow times, or the corresponding overriding effect times...
Thanks for looking into this.
I used extensive effects recently, and I did notice a few peculiarities: in frequent intervals, the 2x LSC ePro dimmers that were connected via the EnTTec USB DMX Pro mk2 reported DMX errors and then reacted erratically and sluggish (with channels that were not part of the chase coming up briefly, and the chase not playing in real time), and although starting and ending the chases I used via the EFXstart and EFXstop command, with "Clear effect on stop" ticked, sometimes levels seem to persist in live (some of which I was able to get rid off after running other effects, and others only disappearing after a restart of the software).
The effects used overriding times of 0 fade up and 0 fade down and 0.25 follow. Is there anything that could conceivably cause these DMX errors in the software? Or in the hardware?
Finally, I once again would have loved a way to influence the playback speed of an effect via command line and/or OSC/MIDI... working like a multiplier on all times used by an effect, i.e. the cue fade and follow times, or the corresponding overriding effect times...
Thanks for looking into this.
Cheers,
Freddy
Freddy
Can you confirm that you are using version 3.4.0?
It may take a bit to reproduce this and having your file might help. It is possible that the new clear time has something to do with the problem with an effect not clearing as expected. Especially if the file was created using an older version.
I'm not sure I follow what the result of the dynamic control you are requesting would be. Can you describe what you want to achieve? (Not what you want to control but what the lighting result is--what does it look like?)
It may take a bit to reproduce this and having your file might help. It is possible that the new clear time has something to do with the problem with an effect not clearing as expected. Especially if the file was created using an older version.
I'm not sure I follow what the result of the dynamic control you are requesting would be. Can you describe what you want to achieve? (Not what you want to control but what the lighting result is--what does it look like?)
-
- Posts: 211
- Joined: Sat Jun 01, 2013 8:23 am
- Location: Adelaide, Australia
I am using version Version 3.4.0 (7408A) , but I can't say for sure that I didn't start the file in a previous version... here is the file
The result of what I try to achieve is to be able to adjust the overall speed or rate of an effect dynamically, as it plays back; say step one fades in over 1, out over 2, and has a follow of 5, step two F/I over 1.5, out over 5, and follow 9, then if the playback rate was 1.0, it would play exactly like that. if however the rate is dynamically changed to say 8.0 (or 800 percent), all times would be devided by 8. Or if the rate goes to 0.5, all times would be doubled. If this is able to be influenced by OSC/MIDI as that effect plays back, than you could slowly accellerate the effect as it plays (one thing that would be cool), and if (as a parameter with EFXstart?) you could pass on a rate straight away, you could play it back consistently straight away...
The application of this, that I have met with in quite a few theatre plays, is say the director uses some club/pop song, that you can program your chases as you like without doing complex math etc straight away, but then with a few goes find out the correct playback rate for this effect to occur in perfect sync with the music. I have used this in the ETC Express/Expression based lighting boards, and it is a great way to also work with a finer resolution than i.e. 0.1 second time intervals (which you can't otherwise in that board).
Also, another question: if you are starting two effects after one another, and the first one isn't stopped, and both effects include some common channels/subchannels, will LXConsole use only Latest Takes Precedence for the (Sub)channels in question? Is there such a thing as successfully running and thus merging two effects at the same time?[/code]
The result of what I try to achieve is to be able to adjust the overall speed or rate of an effect dynamically, as it plays back; say step one fades in over 1, out over 2, and has a follow of 5, step two F/I over 1.5, out over 5, and follow 9, then if the playback rate was 1.0, it would play exactly like that. if however the rate is dynamically changed to say 8.0 (or 800 percent), all times would be devided by 8. Or if the rate goes to 0.5, all times would be doubled. If this is able to be influenced by OSC/MIDI as that effect plays back, than you could slowly accellerate the effect as it plays (one thing that would be cool), and if (as a parameter with EFXstart?) you could pass on a rate straight away, you could play it back consistently straight away...
The application of this, that I have met with in quite a few theatre plays, is say the director uses some club/pop song, that you can program your chases as you like without doing complex math etc straight away, but then with a few goes find out the correct playback rate for this effect to occur in perfect sync with the music. I have used this in the ETC Express/Expression based lighting boards, and it is a great way to also work with a finer resolution than i.e. 0.1 second time intervals (which you can't otherwise in that board).
Also, another question: if you are starting two effects after one another, and the first one isn't stopped, and both effects include some common channels/subchannels, will LXConsole use only Latest Takes Precedence for the (Sub)channels in question? Is there such a thing as successfully running and thus merging two effects at the same time?[/code]
Cheers,
Freddy
Freddy
I tried running a number of the effects in your file at the same time and they all seem to stop/clear properly. Is there a particular set of effects that, when run together, reproduce the problem?
I am just testing this with Art-Net. I'm away from where I have access to a DMX-USB Pro until next week. Not that that should make a difference, but it might if an exception is happening that then prevents something like a clear from completing.
On a side note, ethernet either Art-Net or sACN is much more reliable in a live situation than USB. Although interfaces such as those from ENTTEC or DMXKing are a little more expensive, the flexibility and reliability over a USB box is probably worth it unless you really can't afford one. (In which case, you could make your own using an Arduino, an Ethernet shield and a couple of dollars worth of components)
I am just testing this with Art-Net. I'm away from where I have access to a DMX-USB Pro until next week. Not that that should make a difference, but it might if an exception is happening that then prevents something like a clear from completing.
On a side note, ethernet either Art-Net or sACN is much more reliable in a live situation than USB. Although interfaces such as those from ENTTEC or DMXKing are a little more expensive, the flexibility and reliability over a USB box is probably worth it unless you really can't afford one. (In which case, you could make your own using an Arduino, an Ethernet shield and a couple of dollars worth of components)
There's a new build 3.4.1 (7424A) that improves the thread that updates output for effects. Effects are essentially a dynamic sub-master. When they are running it is like moving a sub master handle up and down. All fine and good except there needs to be a strategy where a cue can run and do its updates in a different thread than the updates caused by an effect. The problem is multiplied when more than one effect wants to update at the same time. Its like listening to AM radio at night when you hear more than one station on a frequency...
The new build uses a dedicated thread to handle all sub master updates, consolidating them. The old method started new a new thread every time an update was needed. I have a feeling that this may have led to some conflicts between threads as well as possibly having more than one update thread talking at a time. The drawback is the processor cycle cost of this thread when nothing is happening. But, the new build handles that by going into an idle mode when no update has been requested for a period of time, only activating the thread when it is needed.
The new build uses a dedicated thread to handle all sub master updates, consolidating them. The old method started new a new thread every time an update was needed. I have a feeling that this may have led to some conflicts between threads as well as possibly having more than one update thread talking at a time. The drawback is the processor cycle cost of this thread when nothing is happening. But, the new build handles that by going into an idle mode when no update has been requested for a period of time, only activating the thread when it is needed.
-
- Posts: 18
- Joined: Sun Jan 26, 2014 4:44 pm
- Location: Canada
I'm curious. I recently had some issues while running LX Console slaved to Isadora. I had about a dozen submasters that were being controlled by MIDI control change messages sent from Isadora. Most of the changes were just on/off, but there were about 3-4 messages (for different submasters) being sent every second for about 3 minutes. On top of that, Isadora was sending MSC go commands to advance cues every 20 seconds or so.
I found that LX Console was crashing about 30% of the time. Crashes were more frequent the second time I ran the sequence without restarting the machine. I assumed that I was simply overwhelming the program and hadn't gotten around to filing a bug report, but what you describe about the effects/submaster processing sounds like it might have been my problem as well.
I'm going into tech tomorrow for a show that is even more complex. I hope to have up to 16 submasters being dynamically controlled via MIDI on top of MSC cues. Hopefully the new build solves the issue and everything will run smoothly.
Craig
I found that LX Console was crashing about 30% of the time. Crashes were more frequent the second time I ran the sequence without restarting the machine. I assumed that I was simply overwhelming the program and hadn't gotten around to filing a bug report, but what you describe about the effects/submaster processing sounds like it might have been my problem as well.
I'm going into tech tomorrow for a show that is even more complex. I hope to have up to 16 submasters being dynamically controlled via MIDI on top of MSC cues. Hopefully the new build solves the issue and everything will run smoothly.
Craig
-
- Posts: 211
- Joined: Sat Jun 01, 2013 8:23 am
- Location: Adelaide, Australia
Thanks Claude for looking into this,
And apologies for the late reply, I was in a complex show. The issues arose when I had one of the intensity-based effects that played on Ch01-17, that are all non-looping and clear on stopping of the effect.
Say effect 1 starts empty (Ch01-17 all @ 00) and chases/builds to all these being @ 100.
Say effect 2 does the same, but in a different order.
When I played effect 1, at the end, all channels were on and stayed on. I expected that because of the "clear when stopped" and "non-looping", the channels might revert to zero or whatever they were set from a previous cue level automatically. Or, at least do that once that specific effect would be called specifically to stop with EFXstop: effect1.
What happened was - all channels stayed on. and when effect 2 was called next, and the first step of that effect was again Ch01-17 all @ 00, this didn't work (potentially, because it ignores zero values as the cannels not being actively set?).
So yeah, those were my specific issues boiled down. However, in the file version that you see, I actually then placed an empty cue at the end of each of those effects, that takes all the intensities back down to zero, that was my work around there. However, the mechanism that I describe above does something that I would at least call counter-intuitive, if not erroneous - or could you explain?
The other matter, the DMX errors shown by the dimmers occurred however even when only ONE effect was running! The AllCues effect just chases over all cues in order, essentially it is like pressing one effect after the other, and then the whole thing loops. so with only one effect playing, this occurred. So are you saying that i.e. this device is more stable and reliable than this device? I suppose you would want to run it either straight from your Ethernet port, or at least via a switch that has no other traffic on it, correct?
Oh, and what did you think of the dynamic rate control for running effect(s)? I think it would be a mighty helpful addition.
And apologies for the late reply, I was in a complex show. The issues arose when I had one of the intensity-based effects that played on Ch01-17, that are all non-looping and clear on stopping of the effect.
Say effect 1 starts empty (Ch01-17 all @ 00) and chases/builds to all these being @ 100.
Say effect 2 does the same, but in a different order.
When I played effect 1, at the end, all channels were on and stayed on. I expected that because of the "clear when stopped" and "non-looping", the channels might revert to zero or whatever they were set from a previous cue level automatically. Or, at least do that once that specific effect would be called specifically to stop with EFXstop: effect1.
What happened was - all channels stayed on. and when effect 2 was called next, and the first step of that effect was again Ch01-17 all @ 00, this didn't work (potentially, because it ignores zero values as the cannels not being actively set?).
So yeah, those were my specific issues boiled down. However, in the file version that you see, I actually then placed an empty cue at the end of each of those effects, that takes all the intensities back down to zero, that was my work around there. However, the mechanism that I describe above does something that I would at least call counter-intuitive, if not erroneous - or could you explain?
The other matter, the DMX errors shown by the dimmers occurred however even when only ONE effect was running! The AllCues effect just chases over all cues in order, essentially it is like pressing one effect after the other, and then the whole thing loops. so with only one effect playing, this occurred. So are you saying that i.e. this device is more stable and reliable than this device? I suppose you would want to run it either straight from your Ethernet port, or at least via a switch that has no other traffic on it, correct?
Oh, and what did you think of the dynamic rate control for running effect(s)? I think it would be a mighty helpful addition.
Cheers,
Freddy
Freddy
Effects are essentially dynamic submasters. Instead of a fixed look like a regular sub, they playback a sequence of cues. But, at any given fixed point in time, they are the same as any other sub master and feed into the combined output on an HTP basis.
Like a regular submaster, an effect has an overall level. Its individual levels come from whatever cues in its list have been played. Clearing the effect sets all of these levels to zero. Because this could be abrupt, having the clear be separate from stop makes sense and allows for the possibility of fading the master before clearing the effect. Clearing is not the same as fading the master because the levels from whatever cue was played by the effect are still in its memory until they are cleared. If you bring the master back up, the levels are still there. To start over if the effect is used again, it is necessary to clear those levels.
Clear after stopped will automatically clear the effect when it is stopped. This could be abrupt, however, if an Out time is assigned, the master will fade to zero and then the effect will clear and be ready to be used again.
In order to do what you want, there would need to be an additional option, something like "stop when finished" for a non-looping effect. That would fade the effect once it had finished with its sequence. (And also possibly clear it if that option was selected.) It seems like adding a black cue at the end of the sequence would achieve a similar thing. The difference being that the effect would still need to be cleared before it was used again. Although a similar thing could be achieved if "clear when stopped" also meant "clear when finished" for a non-looping effect. In that case, the clear time could be used to control how abrupt the end of the sequence was.
Clear when stopped was meant to apply to a looping effect. And the clear time was added later. But, the third solution may be the best now that the issue has come up.
I'm not saying any one device is more reliable than another. I am saying that ethernet based output is more reliable than usb based output. I'm not sure how many times I have to pull a thumb drive out and re-plug it to get the contacts to seat properly. And the same is true for the usb connection ito a dmx widget. The problem with that being intermittent is that you can lose your lights. When an Art-Net or sACN connection drops a packet, it is ignored and it just waits for another one. That's built into the robustness of networking.
Its not necessarily wise to run on the same network as is used for other traffic. But, it is possible. And sACN packet runs about 600 bytes. At a maximum refresh of 40 times a second, (the limit of DMX) that's a data rate of only 24k/sec. Unless someone is streaming a HD movie and using all the bandwidth, DMX over ethernet is really pretty minor in terms of modern networks.
Dynamic rate control for effects can go on the wish list. Right now if you use override times for a chase, the tap button can help find the appropriate times to match music. It sets the follow time to an average of the time difference between the last few taps.
Finally, in regards to the previous post, the refresh of effects and submasters is now handled on a dedicated thread in v3.4.1. This should eliminate problems caused by updates initiated from different threads. However, if the program does crash, using Applications/Utilities/Console.app to view and e-mail the crash report can be the only way to find out what actually happened.
Like a regular submaster, an effect has an overall level. Its individual levels come from whatever cues in its list have been played. Clearing the effect sets all of these levels to zero. Because this could be abrupt, having the clear be separate from stop makes sense and allows for the possibility of fading the master before clearing the effect. Clearing is not the same as fading the master because the levels from whatever cue was played by the effect are still in its memory until they are cleared. If you bring the master back up, the levels are still there. To start over if the effect is used again, it is necessary to clear those levels.
Clear after stopped will automatically clear the effect when it is stopped. This could be abrupt, however, if an Out time is assigned, the master will fade to zero and then the effect will clear and be ready to be used again.
In order to do what you want, there would need to be an additional option, something like "stop when finished" for a non-looping effect. That would fade the effect once it had finished with its sequence. (And also possibly clear it if that option was selected.) It seems like adding a black cue at the end of the sequence would achieve a similar thing. The difference being that the effect would still need to be cleared before it was used again. Although a similar thing could be achieved if "clear when stopped" also meant "clear when finished" for a non-looping effect. In that case, the clear time could be used to control how abrupt the end of the sequence was.
Clear when stopped was meant to apply to a looping effect. And the clear time was added later. But, the third solution may be the best now that the issue has come up.
I'm not saying any one device is more reliable than another. I am saying that ethernet based output is more reliable than usb based output. I'm not sure how many times I have to pull a thumb drive out and re-plug it to get the contacts to seat properly. And the same is true for the usb connection ito a dmx widget. The problem with that being intermittent is that you can lose your lights. When an Art-Net or sACN connection drops a packet, it is ignored and it just waits for another one. That's built into the robustness of networking.
Its not necessarily wise to run on the same network as is used for other traffic. But, it is possible. And sACN packet runs about 600 bytes. At a maximum refresh of 40 times a second, (the limit of DMX) that's a data rate of only 24k/sec. Unless someone is streaming a HD movie and using all the bandwidth, DMX over ethernet is really pretty minor in terms of modern networks.
Dynamic rate control for effects can go on the wish list. Right now if you use override times for a chase, the tap button can help find the appropriate times to match music. It sets the follow time to an average of the time difference between the last few taps.
Finally, in regards to the previous post, the refresh of effects and submasters is now handled on a dedicated thread in v3.4.1. This should eliminate problems caused by updates initiated from different threads. However, if the program does crash, using Applications/Utilities/Console.app to view and e-mail the crash report can be the only way to find out what actually happened.
-
- Posts: 18
- Joined: Sun Jan 26, 2014 4:44 pm
- Location: Canada
Another thing I noticed with effects:
When I set a fade out time but not a fade in time, the effect master would not reset to 100% after the clear. If I ran the same effect twice in the same show, it would not work properly the second time (because the master was at 0). Setting the fade in time to 0.1 seconds solved the problem, but it took me a while to figure out what was going on.
When I set a fade out time but not a fade in time, the effect master would not reset to 100% after the clear. If I ran the same effect twice in the same show, it would not work properly the second time (because the master was at 0). Setting the fade in time to 0.1 seconds solved the problem, but it took me a while to figure out what was going on.
The master reset should be fixed in v 3.4. However, changing the expected behavior creates another problem, how to run an effect starting with a master at less than 100%. In this case, the solution is like what you did. Set a non-zero "in" time and the effect will fade in and stop at the previous master level. Because this is not obvious, it might argue for yet another option for an effect that determines whether to start at the current master level or at 100% (which seems the most likely desired outcome but perhaps not always)
The latest build, 3.4.1 (7426A) changes behavior so that a non-looped effect that reaches the end of its cue list will behave as if it received a stop command instead of just ending.
The latest build, 3.4.1 (7426A) changes behavior so that a non-looped effect that reaches the end of its cue list will behave as if it received a stop command instead of just ending.