Hi Guys/Gals,
First off, I am no LD or know much about programming a GMA2. Networking and video, yes, programming scenes and DMX profiles, no.
One of my co-workers is in the process of programming his GMA2 consoles and wanted to add a video punt page incase there is no VJ or tech for that show. We got a lot of programming knocked out but keep running into a similar problem throughout the process.
It seems that whenever we launch a clip (ex: Layer 1, Clip 3) via DMX, if we turn deck's and try to launch that same clip position (ex: Layer 1, Clip 3), It will not launch that clip until we launch a different clip on that layer first, then it seems to recognize that clip input.
Also it seems that all the clips in the FIRST column will not fire until a different column has been fired first. (We just left column one blank and started everything on column 2 to fix this problem).
I didn't know if anyone else has run across this issue or have more DMX programming knowledge to help fix this?
This is one of the brightest LD's/ system tech's I know, So if it stumps him, i assume it's an actual issue rather than user error? (Still could be user error)
Not a huge issue, just something I thought we might address in some free time.
Thanks
DMX Bug?
Re: DMX Bug?
This is neither user error or a bug, but rather a limitation of DMX in combination with our deck system. The explanation is pretty long, so please bear with me 
DMX works by continuously sending the full universe. There is no such thing as an empty DMX universe. So 25 times per second, the GMA2 will send the values that you've selected on all 512 channels to Resolume. For example, if you just triggered clip 3 by sending DMX channel 8, value 2, the GMA2 will continue sending this until you change the value, at which point it will start continuously sending the new value.
This behaviour is part of the DMX protocol and cannot be changed. For DMX it makes sense, because it makes no difference for a light if you tell it to change to a certain color once, or repeatedly. It will just stick on that color. Better to send it repeatedly to make sure the message arrives, I guess.
For Resolume it does make a difference whether you send a message once or repeatedly, especially with clip triggers. Because you don't want to re-trigger this clip 25 times per second, we ignore these repeated values until a change is detected. So far so good. We've worked around this strange behaviour of DMX and everybody's happy.
But when you change the deck, we have no way of knowing if the value being sent is just the DMX frame being repeated, or if you actually told the GMA2 to send the value again. There is no way to detect this in the incoming DMX data. The incoming data is just the same frame repeated over and over again. Since other media servers don't have the concept of decks, this problem does not exist on other media servers.
So we're a bit in a deadlock. Either the DMX protocol needs to change (ha!), or we need to figure a way around this. Our current idea is to let the range for clip triggers run from value 1 to 255. This way you can use value 0 to "reset" the DMX frame and let Resolume know you're actually ready to trigger a new clip. We can only implement this change on a major release, because otherwise the default fixtures of the desk no longer match.
Does that explain things a bit?
DMX works by continuously sending the full universe. There is no such thing as an empty DMX universe. So 25 times per second, the GMA2 will send the values that you've selected on all 512 channels to Resolume. For example, if you just triggered clip 3 by sending DMX channel 8, value 2, the GMA2 will continue sending this until you change the value, at which point it will start continuously sending the new value.
This behaviour is part of the DMX protocol and cannot be changed. For DMX it makes sense, because it makes no difference for a light if you tell it to change to a certain color once, or repeatedly. It will just stick on that color. Better to send it repeatedly to make sure the message arrives, I guess.
For Resolume it does make a difference whether you send a message once or repeatedly, especially with clip triggers. Because you don't want to re-trigger this clip 25 times per second, we ignore these repeated values until a change is detected. So far so good. We've worked around this strange behaviour of DMX and everybody's happy.
But when you change the deck, we have no way of knowing if the value being sent is just the DMX frame being repeated, or if you actually told the GMA2 to send the value again. There is no way to detect this in the incoming DMX data. The incoming data is just the same frame repeated over and over again. Since other media servers don't have the concept of decks, this problem does not exist on other media servers.
So we're a bit in a deadlock. Either the DMX protocol needs to change (ha!), or we need to figure a way around this. Our current idea is to let the range for clip triggers run from value 1 to 255. This way you can use value 0 to "reset" the DMX frame and let Resolume know you're actually ready to trigger a new clip. We can only implement this change on a major release, because otherwise the default fixtures of the desk no longer match.
Does that explain things a bit?
Re: DMX Bug?
Perfectly Joris!!! Thank you for the explanation. This isn't a dealbreaker for us at all, just a little annoyance (And we all know that DMX is typically to blame for all annoyances haha). I'll forward this along to my LD so he can at least have a little bit of closure on his question.
Thanks for all the help as usual! You're the best!
Thanks for all the help as usual! You're the best!
Re: DMX Bug?
The solution to this requires alot more programming and channels on your MA2. This work around probably won't be picked up by your LD, simply because it takes awhile to program in resolume and is going to need a macro on the MA unless you want to manually create all the playbacks or cues.
I'm assuming your using one channel per layer and per column. Everything Joris has said is correct.
If this really annoys your LD and he has lots of time, you can map a single channel to each clip and column trigger instead of one channel per layer. Sure your going to eat up acouple universes when it was acouple channels but you'll be able to get around this.
Now when you flash a channel that triggers what you need since your going from 0 - 255 instead of staying at the same channel value.
I'm assuming your using one channel per layer and per column. Everything Joris has said is correct.
If this really annoys your LD and he has lots of time, you can map a single channel to each clip and column trigger instead of one channel per layer. Sure your going to eat up acouple universes when it was acouple channels but you'll be able to get around this.
Now when you flash a channel that triggers what you need since your going from 0 - 255 instead of staying at the same channel value.
Re: DMX Bug?
Thanks drazkers,
This was discussed as well but like you said, more work than we care to do. The video will be a very small aspect of his show file, and honestly with 40 clips per deck, the odds of him needing the same clip on the same column and layer when switching is very minimal at best (and would be easier to move the clips around at that point)
However with master FX loaded, we will be doing custom programming for that, but to make a custom layer map, nah, he'll manage.
Thanks for the reply
This was discussed as well but like you said, more work than we care to do. The video will be a very small aspect of his show file, and honestly with 40 clips per deck, the odds of him needing the same clip on the same column and layer when switching is very minimal at best (and would be easier to move the clips around at that point)
However with master FX loaded, we will be doing custom programming for that, but to make a custom layer map, nah, he'll manage.
Thanks for the reply