PlaybackMode and In Frame Question

I have a sequence that is not playing back as expected. Probably my error, but I can't figure it out. Please help.
The Q sequence: (I am refering to console cues, not Catalyst cues)

Q142 - Layer 4: Set playback Mode to "Display in frame" Set In frame to frame 150, Time 0. Playback Speed is set to 1 (Pause.) All other parameters are at "default." Level is at 0.

Q145 - Layer 4: Level to full, Time 4, Set In frame to frame 150, time 0.

Q146 - Layer 4: Set Playback Mode to "Play Once Forward." Playback speed is setn to 128 (full) Time .4. Also change In frame to 151, Time 0.

What I expect to hapen:
Q142 - Nothing visible - just loading the movie
Q145 - Still image of frame 150 fades up in a 4 count
Q146 - Movie plays forward from frame 150

What actually happens:
Q142 - Nothing visible
Q145 - Still Image of Frame 1 fades up in a 4 count
Q146 - Movie jumps from frame 1 to frame 151 and then plays forward.

For some reason it seams like Catalyst is not getting the message that it should be in frame 150. Even though I send that DMX in both Q142 and Q145.
The reason that I set the In Frame to 151 in Q146 is that I found that if I did not (ie left it at frame 150) the movie would play back from frame 1 in Q146 everytime.

I am controlling the Catalyst through Artnet, with no CIB, (sorry to be redundant.)

I have gone to the trouble to capture the Artnet packets at the cue times, and the DMX levels coming from my console are what I have described above.

Layer 4 is used in the previous cues. The last time it is used it is displaying a .png, so the Playback Mode, In/Out Frame etc remain at default.

Is there a specific order or timing in which Catalyst needs; relating to file selection, Playback Mode, and setting the in frame?

Any thoughts on why the described sequence might be playing back as described? I am sure I am missing something simple, I am a "noob" after all.

Thanx for your help.

in cue 145 - you say you see frame 1 appear - not frame 150?

which console is this?

Richard,
Yes in Q145 the movie fades up in Frame 1 not frame 150 as I would expect.
Console: is a homebrewed application that we wrote here at OSF. That is why I checked the actual Artnet Packets to make sure I was sending the correct DMX to Catalyst. Our app has worked for us for a couple of years as our moving light console, we adapted the code a bit to deal with Catalyst with a friendly GUI.
MKM

Quote:

---

Originally Posted by longred

Richard,
Yes in Q145 the movie fades up in Frame 1 not frame 150 as I would expect.
Console: is a homebrewed application that we wrote here at OSF. That is why I checked the actual Artnet Packets to make sure I was sending the correct DMX to Catalyst. Our app has worked for us for a couple of years as our moving light console, we adapted the code a bit to deal with Catalyst with a friendly GUI.
MKM

---

and what dmx values in what channels did you see?

Richard,
Here is the DMX for Layer 4. Let me know if you want the entire DMX stream.
Q137 Q142 Q145 Q146
Chan DMX Chan DMX Chan DMX Chan DMX
121 3 121 3 121 3 121 3
122 3 122 77 122 77 122 77
123 0 123 0 123 0 123 0
124 0 124 150 124 150 124 151
125 0 125 0 125 0 125 0
126 0 126 0 126 0 126 0
127 0 127 0 127 0 127 4
128 0 128 0 128 0 128 128
129 128 129 128 129 128 129 128
130 0 130 0 130 0 130 0
131 128 131 128 131 128 131 128
132 0 132 0 132 0 132 0
133 128 133 128 133 128 133 128
134 0 134 0 134 0 134 0
135 139 135 138 135 138 135 138
136 221 136 99 136 99 136 99
137 128 137 127 137 127 137 127
138 0 138 244 138 244 138 244
139 128 139 127 139 127 139 127
140 0 140 112 140 112 140 112
141 0 141 0 141 0 141 0
142 0 142 0 142 0 142 0
143 0 143 0 143 255 143 255
144 255 144 255 144 255 144 255
145 255 145 255 145 255 145 255
146 255 146 255 146 255 146 255
147 0 147 0 147 0 147 0
148 0 148 0 148 0 148 0
149 0 149 0 149 0 149 0
150 0 150 0 150 0 150 0
151 0 151 0 151 0 151 0
152 0 152 0 152 0 152 0
153 128 153 128 153 128 153 128
154 128 154 128 154 128 154 128
155 128 155 128 155 128 155 128
156 128 156 128 156 128 156 128
157 128 157 128 157 128 157 128
158 128 158 128 158 128 158 128
159 128 159 128 159 128 159 128
160 128 160 128 160 128 160 128
Thanks again for your help.
Michael

Eek that looks like poo, what happened to my formatting? Let me know if you want me to send you a text file or something that is more legible.
Michael

I always find it best to try and change as few parameters as possible in a cue. In Q146 you change both the mode and the speed. A few possible solutions:

1. Try setting the mode to "Play Once Forward" in Q142. This should be fine because pause should hold it. If pause is stopping it from presetting to frame 150, you could try playing at full speed and just bracketing frame 150 with in and out. So now it's basically just playing frame 150 over and over again until you change your outframe in Q146. <Edit: in order for this bracketing to work, you may have to set mode to "Play Loop Forward">

2. Rather than changing play mode in Q142, try changing play speed to "full speed" in Q142. Now the only thing you are changing in Q146 is play mode, and also possibly the inframe from 150 to 151.

I think option 2 here is going to be the cleanest solution.

Josh,
Thanx for the suggestions. Have you found that changing multiple parameters in cue(simultaneously) is problematic?
I'll try your cueing suggestions and see what happens. I like the changing the out frame idea, I never would have thought of that option.
I'll post my results.
Michael

what you have here is parameters that interact.

I cant repeat what you see-

but in this example you dont need to change the playback speed in any cue.
'Inframe' playmode does not play. Leave playback speed at 100%

Also suggest you check the commands you think you are sending to catalyst - using the catalyst GUI.

For example when you say frame 1 - your user interface is using an offset from 1 - my user interface uses an ofset from 0.

As Richard said the parameters are interacting, meaning...the behavior of one parameter is dependent on the setting of another. It's kind of like "gobo rotation" and "gobo function" in moving lights. The behavior of "gobo rotation" is dependent on which mode "gobo function" is set to.

Also, the more parameters you change, the more processing catalyst has to do. This is especially applicable if you fade between two different values, even if it's on a layer that isn't visible. Basically you are sending 1000's of commands to catalyst over the course of a few seconds. It just can't process changes that fast. I often see choppy fades and video playback because of this.

My rule of thumb is "change as little as possible, and do it as quickly as possible."

Once again as Richard suggested, the GUI really is the best tool for figuring things out. It's far more intuitive than any lighting console interface. Play around with the GUI. Snapshot some presets that do what you want, then recreate those settings from the console.

catalyst doesnt have to do any more processing if you change lots of parameters.
changing playmodes or movie speeds has no impact.

what affects performance is the number of layers of movies and loading movie.
what affects things is when movie frames have to be fetched from disc.

So you're saying it makes no difference if you send all the changes once in a single dmx packet vs. sending lots (1000's) of changes over a few seconds fading between values? Did you code it to parse the dmx packets and only pass the state changes to the data model, or did you code it to be constantly updating the data model with every dmx packet parsed?

Richard and Josh,
Thanx for your patience and guidance.
Richard you wrote:
"what you have here is parameters that interact.

I cant repeat what you see-

but in this example you dont need to change the playback speed in any cue.
'Inframe' playmode does not play. Leave playback speed at 100%

Also suggest you check the commands you think you are sending to catalyst - using the catalyst GUI.

For example when you say frame 1 - your user interface is using an offset from 1 - my user interface uses an ofset from 0."

Sorry about the reference to Frame 1 instead of Frame 0 that is just my newbieness showing. I used the wrong terminology.

Which parameters are interacting in this sequence?
Play Mode and InFrame - I expect that
Play Mode and Playback Speed - I expect that too
InFrame and Playback Speed - probably not, right?

In the sequence described, I change the playback speed because the designer wanted to see the movie start slower and then play at speed, essentially giving the movie a slow bottom.

Given that some parameters interact, then how do they interact? For example If I know that I need to select Playback Speed before Play Mode then I can construct my cues to get my desired result.
Thanks again.
Michael

Quote:

---

Originally Posted by joshgubler

Did you code it to parse the dmx packets and only pass the state changes to the data model, or did you code it to be constantly updating the data model with every dmx packet parsed?

---

By way of introduction I wrote the interface that longred is using and I am helping to figure out what is going on in this cue sequence. My guess is the above question from josh is key, my guess is that Cataylst only acts on state changes. It makes sense, it is the way I would do it, especially with dealing with a streaming protocol like DMX.

Our cue 142 as above is really doing 3 things (am I correct Michael?) it is selecting a file (movie), setting Play mode to Display InFrame and setting the Inframe to 150.

We will test this in production tomorrow but my guess is that this is a timing issue (if Catalyst is just looking for state changes). All 3 things listed above are arriving in the same artnet packet (have sniffed using wireshark and my own packet sniffing software), my guess is that it is taking too long to load the movie and that by the time it is loaded Catalyst doesn't think it has to do anything or it thinks that it has set it to frame 150.

What we will do tomorrow is delay the setting of the inframe for a couple seconds so that the movie is loaded before setting the Inframe to 150.

Fun stuff :)

Stuart Cotts

Personally I have a strong feeling it is something in the console end, as i do things like this all the time, and have never had an issue with it doing what it should, when it should. Even when changing lots of parameters at the same time, it always keeps up. The only time I ever see some sort of a puase, etc is when loading a large file for the first time.
I have had issues in the past where doing just what you are trying to do, and when I had problems it had to do with what information was stored in the previos/next cue etc. Or soemthing else running had something stored in it that cause the jump etc.
I would definitely be lookin got the board more than anything else.

Quote:

---

Originally Posted by stucotts

By way of introduction I wrote the interface that longred is using and I am helping to figure out what is going on in this cue sequence. My guess is the above question from josh is key, my guess is that Cataylst only acts on state changes. It makes sense, it is the way I would do it, especially with dealing with a streaming protocol like DMX.

---

yes. test your state changes.
dmx is a data stream not a command stream.
this is inherent in dmx.

they have to be thought through differently.

I have done my best in the past to try and work through these issues - and create a usable protocol without too many issues for the simplest of lighting consoles.

you need to change your states, and check what you see catalyst do, by looking in my HUD - it will show you everything you need.

---
another inherent problem is the defintion of 1 or 0 to be the floor state. - and how this is displayed to the user.
dmx values range from 0 to 255 per channel.
so 0 value has real meaning in dmx.

Quote:

---

Originally Posted by samsc

yes. test your state changes.
dmx is a data stream not a command stream.

this is inherent in dmx.

they have to be thought through differently.

I have done my best in the past to try and work through these issues - and create a usable protocol without too many issues for the simplest of lighting consoles.

you need to change your states, and check what you see catalyst do, by looking in my HUD - it will show you everything you need.

---
another inherent problem is the defintion of 1 or 0 to be the floor state. - and how this is displayed to the user.
dmx values range from 0 to 255 per channel.
so 0 value has real meaning in dmx.

---

I know and understand DMX and state machines very well.

We found the problem today, it is a Catalyst problem.

As I mentioned the other night we are changing 3 things on this layer at the same time - selecting a somewhat large movie, setting playmode to Display InFrame and setting InFrame to 150. As we have seen over several performances and through packet analysis through wireshark. The movie is selected, Playmode is "display Inframe" and Inframe via HUD/Wireshark and all artnet monitoring devices is shown to be at 150 yet Catalyst is displaying frame 0 (1st frame of the movie)

We changed the cueing today so that the first cue selects the movie and sets PlayMode to Display InFrame and then a few seconds later set InFrame to 150 and all worked fine.

So it appears to me that the movie takes some time to load and by the time it is loaded Catalyst has tossed the state change from frame 0 to frame 150.

>>I have done my best in the past to try and work through these issues

I totally understand. You have done very well, Catalyst is a good product.

This is a minor issue but nonetheless an issue, it means that we need to be aware of not being able to pass all layer changes at once, probably when loading larger movies or maybe it is when several layers are doing 'some' amount of processing.

I find it a breath of fresh air that the developer of such a product is available to its users to ask questions and work through issues.

Thank-you,
Stuart

>>and create a usable protocol without too many issues for the simplest of lighting consoles.

I am curious, are you thinking of supporting ACN in the future?

Stuart

Quote:

---

Originally Posted by stucotts

>>and create a usable protocol without too many issues for the simplest of lighting consoles.

I am curious, are you thinking of supporting ACN in the future?

Stuart

---

i like simple things.

i heard it was complex.

Quote:

---

Originally Posted by stucotts

As I mentioned the other night we are changing 3 things on this layer at the same time - selecting a somewhat large movie, setting playmode to Display InFrame and setting InFrame to 150. As we have seen over several performances and through packet analysis through wireshark. The movie is selected, Playmode is "display Inframe" and Inframe via HUD/Wireshark and all artnet monitoring devices is shown to be at 150 yet Catalyst is displaying frame 0 (1st frame of the movie)

We changed the cueing today so that the first cue selects the movie and sets PlayMode to Display InFrame and then a few seconds later set InFrame to 150 and all worked fine.

So it appears to me that the movie takes some time to load and by the time it is loaded Catalyst has tossed the state change from frame 0 to frame 150.

---

it takes some time to "load a movie", and some time to get a particular frame in a movie. depends on many thing.
On my laptop here with internal drive it takes 40ms to load dv movie, and 10ms to get each frame.

there might be state interactions if you change state too quickly.
it might depend on the dmx update rate of your console.
Im checking some more.

Quote:

---

Originally Posted by samsc

i like simple things.

i heard it was complex.

---

At its core there are parts that are complex but very nicely ACN is being developed in opensource. For me SDT would be a bear to code.

DMX is a great protocol to replace what it replaced, streaming analog for dimmers. But at the end of the day the get/set properties of DMP will be wonderful for state machines such as moving lights, media servers, etc.

Check out
http://www.openacn.org/

I have been an observer to the ACN task group (I am missing the Phoenix meetings as I write) and it is a great group of people.

Stuart

You need to do really clean and organised programming for media server programming. Play modes and in frame/out frame can really trip you up if you're not careful. A common technique with media server programming if firstly to 'preload' up coming movies on other layers (that's why you have 12 layers, right!).

DMX is a bit pants for media servers - but it's all we have at the moment. Who knows when ACN will be out...

Hugh

Quote:

---

Originally Posted by Spam Butterfly

A common technique with media server programming if firstly to 'preload' up coming movies on other layers (that's why you have 12 layers, right!).

DMX is a bit pants for media servers - but it's all we have at the moment. Who knows when ACN will be out...

Hugh

---

True... preroll is preroll. And that is how most state machines function...

But in this case Catalyst breaks the paradigm of what DMX is. And we cannot forget that DMX is a streaming protocol. All other devices out there do not act as state machines and only change when the state of the stream changes. If that is how the device needs to react then error checking is programmed to conform. Catalyst could see the request for loading a moive and request for InFrame of 150 and in the same packet and wait to do the Inframe when it is vaild to do.

All other devices out there in the world on a streaming protocol change when the stream changes. So it is an error for the movie to be in the state of frame 0 when the stream is asking for frame 150. 1 second/ 15 seconds later.... Irregardless of preloading/ preroll, on a streaming protocol this is an error.

Stuart