• State Suggested Answer
  • Date
    jordanhenshaw
  • Date
  • Replies 23 replies
  • Answers 3 answers
  • Subscribers 189 subscribers
  • Views 2059 views
  • Users 0 members are here

Automark Refuses to Die Unless I Pay it $100 worth of Time

Hello,

No matter what I do, most of the time when I try to kill auto marks, they refuse to die. I want a group of movers to stay in a certain position with intensity at zero on Cue 2. During cue 2, I have effects firing intermittently and they MUST stay on the focus pallette I have recorded into that cue. On cue 3, I manually mark them to a new focus palette so they can be ready for a fly out fan effect in cue 4. However, no matter how many times I record them as Preset 1 on cue 2, they refuse to be at that spot during cue 2. They want to mark to their position for cue 3 once cue 2 comes up. They think it's safe to do so since the intensity is at 0. But I have effects firing from OSC. So they MUST stay put. I go Cue 2 Disable Automark Enter and the M in PSD goes away. No change. I have ensured the main settings have automark disabled. No change. I have gone Group 18 Preset 1 Enter, "Group 18 Record Cue 2 Enter" 5 times. I am going insane. The ONLY way to kill this stupid automark is to keep intensity at 1. This is absolutely ridiculous that I have to add mistakes into the light design just to get the lights to stay where I want them to stay. There are 2 different ways I know of for killing automarks and neither of them are killing the automarks. 

No matter how many times I record this group to the position I want, they absolutely REFUSE to go there at that time because the lamp is off inside the cue and that means they think they can do whatever they want. As if no one has ever heard of the concept of intensity effects that aren't built into the cues.

1. Automark is disabled in the settings and has been for decades.

2. Group 18 Preset 1 Enter (this makes them pan/tilt to Preset 1)

3. Group 18 Record Cue 2 Enter (this should tell them to go to Preset 1 pan/tilt when we go to cue 2. In Preset 1 their intensities are all at zero, but intensity effects will be firing through OSC during this cue so they must stay in this pan/tilt)

4. Go to Cue 19 Enter (Now we are going to tell them to move to Preset 2 when Cue 19 comes up)

5. Group 18 Preset 2 Enter (Now they move to their new focus palette to get ready for a fan/fly out effect in cue 20. Their intensities are still all at zero inside the cue. On Cue 21, the intensities will come up inside the cue.)

6. Group 18 Record Cue 19 Enter (This should tell Eos these lights should move to that pan/tilt during Cue 19). 

7. Go to cue 18 enter (The lights do not move. They stay at the pan/tilt for cue 19, preset 2. They MUST move to cue 18's pan/tilt. 

8. Cue 18 AutoMark Off Enter (This changes nothing. In cue 2, the lights still automark despite the PSD showing zero nearby M's)

9. Cue 17 thru 19 AutoMark Off Enter (Now the lights stop automarking. Now they stay at the proper pan/tilt.

So technically I just got it to do what I want. Am I allowed to cuss here? Why the you know what is it so bloody difficult to get these automarks to stop you-know-whatting-up my show? Why do none of the automark disabling features work as expected? Why does the PSD not show M when automarks are screwing with cues?

What is going on here?

Best regards,

Jordan

  • 0 in reply to jordanhenshaw
    jordanhenshaw said:
    I can't reproduce the effects issue

    Would you happen to have performed a software update in the meantime? What you're describing was a bug that was fixed in 3.1.0, where the Effect Editor wouldn't correctly populate the CIA if you tried opening it while you had a selection in the command line.

    As I mentioned this should have been fixed for close to two years.

  • 0 in reply to jordanhenshaw

    Ok, so to be blunt, it's not a real thing. I'm familiar with video keyframes. Lighting doesn't use them, but I of course welcome you to develop the technology.

    In your bouncing logo example, I would do one of two approaches, depending on how video programmed it. If the logo is an object they are translating across the screen, I would ask them to connect it to PSN and send me the datastream, and use something like Zac Tracks or Blacktrax to read the PSN and point a light at the logo. If it's just a movie and I can't have position information, I would set up timecode to start with video, ask what time each move started, add a cue to that timestamp, and then how long until the next move, set the cue time. Probably 60 seconds per move worth of programming. This does however assume linear motion, and takes some amount of programming time, so PSN is highly preferable. Regardless, the entire 60 second clip is programmed in maybe 15 minutes using existing techniques and technology.

    Your proposed keyframing solution doesn't really remove any of the friction - I still have to know what time each position happens at (which I can still learn from paused timecode with normal cues on Eos) and point a light there., it's just doing the "Cue time X Enter" command for me in the background.

    You're not going to make a ML follow a dancer's arms in sync no matter how you save the data - you have to have real time tracking. Get Zac Tracks.

    These are solved problems with existing techniques and technology. I'm always willing to be wrong and adopt better technology as it develops, but I don't think any of your examples require me to abandon the way current cues function - you can always set cue time to equal the difference in time between two cues in your timecode sequence.

    The real opening your mind to the possibilities of motion is real time tracking and PSN. You tell your light to "point at X", and just give it the data on where X is. This is routine to use for followspots, video objects, and scenery - you can calibrate with known positions (Chandelier 1 is at XYZ when the motor is 20' spooled out) or use radio/IR trackers to allow complete freedom of movement. Do a little zoom calibration and your fixtures can even keep a consistent size as they move around with complete freedom.

  • 0 in reply to Taylor C Jensen

    It's very close to being a real thing.

    Linear start/stop motion is easiest. Now try to track a 3D audio object circling the room, curving, and doing all sorts of turns without ever stopping. Obviously you'll have gimbal lock issues, so you'll also have to swap movers mid-move without making it obvious you swapped. 

    That's a real problem I worked on once. Couldn't finish it because cues made it impossible. 

    Last week, a Visual Lighting Sequencer wasn't a real thing either. Next week I'll be working on getting Intensity/Pan/Tilt keyframable inside the sequencer.


  • 0 in reply to eos moderator

    I got into the habit of choosing Element mode quite a while back, so it's not inconceivable to think that software I was running at that time was pre-3.1.0. It's quite likely actually. Funny how one seemingly unrelated bug can result in completely different problems in completely different parts of the software. The thing that says Mark Time = Disabled is really dumb though. Should say Mark Time = Cue Timing.

  • 0

    Love this thread. Respectful interchange of ideas and learning new things. This is what a forum should be like!

  • 0 in reply to jordanhenshaw

    I agree that it is poorly named and not intuitive. It's in the manual, but I shouldn't have to have the manual next to me decoding what things mean 24/7. If the name and purpose can be intuitive, they should be, and this is definitely one of those cases where they can improve it.

  • 0 in reply to Taylor C Jensen

    "Ok, so to be blunt, it's not a real thing." - It became a real thing an hour ago. ETC Eos can now be controlled with keyframes.

  • 0 in reply to jordanhenshaw

    I'd love to check it out, let me know where I can find the software.

Related

www.etcconnect.com