Smpte ignored by Simulate?

Hi Bhagat,

This is as designed. When simulate is activated it steps in and takes over control of timecode for that input device. This feature is really only meant to be turned on when the timecode source is not available.

Hi,

I thought as much. Yet, in my case, a showstopper! I must be more carefull when closing a window which is over that button. Nevertheless, one could also think that incoming timecode is stopped only after pressing 'go' in the simulate window, just out of precaution.
What worried me most, was the fact that smpte stopped at bóth networked hog's, that why I posted. Is that as designed as well?
Now, this is a setup I only operate now and then, and after some closer inspection, I found out that instead of there being a Console1 and 2, as it should, both consoles are number 2! I suppose this must have happened after the latest upgrade the other operators did, but failed to notice. It does explain that both consoles stopped the smpte. Yet, if you could answer the question above, I would be much obliged.

"smpte stopped at both networked hogs"... Is that as designed as well?"

Yes. Each console on the network that is capable of receiving timecode acts as a timecode source for the entire network. Each cuelist has the option to choose which node on the network you want to listen to for timecode. If the timecode node that the cuelist is listening to stops running, then the cuelist stops and since the cuelist is shared by all the desks on the network, then it applies to all desks.

As far as both consoles being set to net #2... the software shouldn't even allow you to log on as console #2 if console #2 is already acting as the show server. But in any case, this is not why timecode stopped on both consoles. That happens for the reason I explained above.

Ok,

Thanks for the explanation. The consoles having the same number is strange indeed. It does explain 1 thing though. In this show there's a part thats run ( ran?) manually, on a separate list. About every 3-4 cue's, a pagechange is fired through a comment macro. Because these pagechanges could go too slow, the same pagechange was also explicitly done on console no1 ( the hpc server) by these macro's, this to ensure lists were fired even though the page wasn't loaded fully yet on the hog3 (console2)
After the upgrade all the cph1 macro's were gone! Wonder if they'll be back if console 1 is reinstalled..
It still amazes me no-one registered the fact that console1 was gone in the first place!