-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add DMX parameters for Moving Head Models so Previews are Accurate #848
Comments
That could get complicated. My heads have normal and high speeds. The speed is dependent on the value of channel #8. The head tilts/pans on channels #5 and #9. I just learned to pre-position the head when it's needed to be at at position X then when the timing comes, turn on the light. I do 100% understand the preview not showing where the head actually is, it only animates based on the command sent. Just like xLights does not show the lag when using unicast and a controller is missing. Whatcha think Gil, can it be done? |
I understand pre-positioning, that is what I do to. But the preview does not have to know where the head is in the range of motion, if it used a variable for the time it takes to move that is good enough to know that if you issue a command too soon then you are interrupting the completion of the previous command, plus the preview would be accurate enough so you can sequence from the preview. If you used value curves on your pan and tilt channels then it is good enough to sequence from the preview, the problem is with heads like mine the values curves are much slower than the heads internal interpolation when you just send it a position command. The way my sequence looks is that I issue a DMX value, then for the next x seconds there is nothing in that row for the sequencer and then another command is issued and the preview model jumps to the new position, I do that over and over and for the two seconds between when command one was issued and command two is issued the preview model just shows it in position one, then when it gets too command #2 it flips over. The end result is that it looks nothing like what is really happening with the head and I am forced to actually sequence with the heads connected to the computer and ignore the preview. While I realize this can be a slippery slope to a lot of other functionality that would be nice to put in parameters for the model, this one request will at least make the preview usable so I do not want to convolute this issue with all these other values that you should be able to set for a DMX model at this time. If we just had a speed value for the DMX channel and then make the preview animate from the current value to the next value at that speed for that channel (until it either completed the command or encountered a new, conflicting command) then it would be sufficient. I actually talked to both Keith and Gil about this last year but everyone agreed it would have to wait until this year but it would be nice to have it before the summer. |
The code you checked in was for #744 right? That is what we were talking about on Facebook, this issue is different, it has to with timing, not the value scale. |
No I haven't done 744. I said that was global to all value curves and not related to DMX. The code I checked in yesterday has Pan and Tilt Slew limits. So you can set it for say 60 deg/sec and if you do a move from 255 to 1 it slews in the preview over time not an immediate jump. Pretty much what I thought you just posted here. It doesn't handle Steve's multiple speed scenario. |
Have you tried the slew rates? I believe it satisfies this one. |
Yes, this is resolved, thanks! |
If I issue DMX value 255 and then immediately issue DMX value 1 the model preview will just show the head flip when in reality it takes 2-seconds to rotate. I think some kind of parameter should be added to the model so you can set how fast your head is, then if you issue value 255 the preview will show it rotating and if you issue another DMX value too soon then it shows what the head does in real life (which is interupt the first command pan with the second command pan). Not only does this make the preview accurate but it allows you to watch the preview to see how long you need to wait in your sequencer before adding the next command so your previous one can complete.
The text was updated successfully, but these errors were encountered: