Jump to content
Zero 88 Community Support Forum
Sign in to follow this  
RAW Lighting Power

Problem With Effects Generator

Recommended Posts

I have got my Leap Frog out on a tour. We plotted the show and for some reason during plotting, the index finger wheel didn't work. However after rebooting the console it worked.

 

I saved the show, but on rebooting for the dress run the next day, many of my scenes appeared to have a movement effect on them which weren't present when I plotted.

 

I edited them all out and ran the rehersal. The next day (even after saving the show to disk) the effect were back in my scenes.

 

The dress rehersal then ran.

 

We then moved to another theatre to open the show, and when I tried running the cues, once again there were the effects.

 

I edited everything again and saved it.

 

Last night we moved the show again, and when I went to check the cues before the show, effects were again present on the cues!!

 

I have checked that I haven't saved them into the pallets but I'm at a bit of a loss.

 

I'm running FrogOS 9.2 with 23 moving light patches and various generics.

 

Can anybody help?

Share this post


Link to post
Share on other sites

Hi all,

I was about to post the same report myself. A fellow from another lighting company subhired one of our frogs last week and when he brought it back on Saturday he said he had the exact same problem not only with our Fat Frog but his own one as well. I set up the desk and a coulpe of Macs in the warehouse and prgrammed about 10 static cues and 2 with shapes on them. I put them on submasters and ran them I also used the cue stack with the Go button and every thing seemed fine, I even turned the desk off and left it for a while, when I turned it back on later it still worked fine. I could not get the error to repeat itself so I put it down to pilot error but now that somebody else has expirienced the same problem I am not so sure.

Share this post


Link to post
Share on other sites

If possible could you send us a copy of your show file and some information on which scenes/memories have these rogue movement effects on them. We can then set up a desk here and investigate further.

 

Were the scenes referencing position palettes at all ?

Share this post


Link to post
Share on other sites

Hi,

Unfortunately the desk was wiped when returned so I cant send you a show file but perhaps RAW can. When I done my test, one thing I did not do was to put a shape on a pallet and associate it with a memory. Iwill try that later on today if I get a chance. The other thing I did not do was add any generic channels into the scenes but I fail to see why that would cause it to happen.

Share this post


Link to post
Share on other sites

Even if you didn't put a movement effect (shape) into a position palette, were you referencing position palettes from your memories ?

 

It's just that one of the changes in Release 9.0 was to allow movement effects to be recorded in position palettes, whereas previously it would just snapshot the pan/tilt output values.

 

There were a few bugs in the beta software in this functionality and I was wondering whether this current problem may be related :?:

Share this post


Link to post
Share on other sites

yes the whole show references from pallets. I have emailled the show file to keith. When editing the show i re-editted the pallets as some of them were experiencing the same problem so i made sure there were no movements on my pallets

Share this post


Link to post
Share on other sites

Do you notice these rogue movement effects after power cycling the desk or reloading a saved show from floppy ?

 

I was wondering if it was the reloading of the show file from flash (after a power cycle) or from floppy that may somehow be corrupting the position palettes that you have recorded

Share this post


Link to post
Share on other sites

Hi,

No none of the memories I programmed referenced any pallets but I will contact the chap who was using the desk and check with him if he was using position pallets. I imagine he would have been as he did say he had abot 100 cues in his show.

Share this post


Link to post
Share on other sites

One of our LDs had a similar problem I think, I'll ask him to read this post and give his comment.

Share this post


Link to post
Share on other sites

Hi,

 

I'm the LD ice told you about. I was having the exact same problem (if I understand all your lingo right). I saved a static position pallet, and when recalled using a memory or a submaster (after a reboot) the static pallet changed itself into a moving one.

The strange thing I think I noticed is that if I loaded the show from a floppy, this effect happend, but when I loaded the show from flash ( essentially just turning the frog on) this problem wasn't encounterd. This wans't an option for me though, because the flash memory tends to forget the submasters.

Unfortunately I don't run the show anymore, so if you have further questions I'll have to try to remember.

 

Good luck finding the problem!

 

Enrique.

 

ps. I'm glad other people were also experiencing these problems, I thought I was losing it :)

Share this post


Link to post
Share on other sites

Well done, Enrique, I think you've just remembered the important factor :D

 

I have just tried it on a fat frog here, and the small rogue movement effects appear on the memories which were referencing static position palettes previously ... after you reload the show from floppy disk !

 

When I turned the desk off/on and effectively reloaded the show from flash, it looked OK.

 

I will pass this information on to our software guy for further investigation.

Share this post


Link to post
Share on other sites

This may be the case for some of you, but we're having the same problem loading from flash memory. Only on one of the shows did we reload the show from floppy. If the show file I sent isn't enough, I have another few backup versions on disk which I could send if that helps.

Share this post


Link to post
Share on other sites

I believe that when you are programming memories etc. on the desk, the data is stored in NVR first and then when that is full, the data is backed up onto flash.

 

Maybe in my recent tests I have not programmed enough new data for the show to be backed to flash.

 

As you have observed there also appears to be a problem when power cycling the desk, which results in the show file being reloaded from the flash memory.

 

I'm sure our software guy will correct me if I'm wrong, but reloading the show from flash or floppy should be the same.

 

I was just saying that in my recent tests, I could only reproduce the bug when reloading from floppy disk.

 

Frog Reference No 5482 - Movement effects appear on memories after reloading show file from floppy or power cycling the desk - To be investigated.

 

This problem is being looked into at the moment. We hope to have it fixed and a new version of software available by the end of this week (or early next week due to the Bank Holidays).

 

As soon as the new software is available it will be announced in the Software Releases forum.

Share this post


Link to post
Share on other sites

While programming a gig tonight onto the subs page one, after reaching sub 12, I went to play back the subs to check everything, DISASTER all the subs had the same duck effect stored on them 8O .

What the duck happened. All the fixtures were homed after each sub was programmed. I'm running the desk in 9.2, any ideas :?:

Share this post


Link to post
Share on other sites

Hi Gary,

Its a bug in the software release 9.2 so upgrade to 9.6 to cure that problem. The thing is Release 9.6 also has a bug which causes subs that have been programmed either with or without times to revert to the default memory fade up/down times after the desk reloads the show from flash memory. Its not a major problem just one to keep an eye on ,(unless you discover it 2 minutes before the show starts ). Just reload you memories onto the subs as you want them and everything is ok.Although if you have recorded your scenes straight to subs as channel data, I am not to sure how that pans out.

Share this post


Link to post
Share on other sites

The bug with the times on submasters relates to those with transferred memories only.

 

When the submaster data is reloaded from flash, you get the memory fade times rather than the correct times for the submasters.

 

Therefore it is only really a problem if you have transferred the memories without time, or have have transferred them with time and subsequently adjusted the times for individual submasters.

 

The times on submasters programmed directly with channel/fixture data appear to reload correctly.

Share this post


Link to post
Share on other sites

Loaded ver. 9.6, did a show yesterday same fault.

Programmed the generics directly onto the first 6 subs page one. Turned off the desk went to get the nose bag, returned powered up everything started to program the movers directly to the subs, when finished playing, went back to check everything and FU@K all the generic memorys has the last programmed mover state recorded on them :cry:

Powered off/on the desk and it was still the same, the last recorded mover state had copied itself over ONLY the first 6 subs where the generic info lived.

Any ideas cause my heads wrecked.

Share this post


Link to post
Share on other sites

I'm slightly confused here GLX :?

 

Which submasters were you programming the movers onto, ie which page and which submaster numbers ?

 

Were the movers being programmed on the same page or a different page ?

 

Were you overwriting or editing the previously programmed submasters perhaps ?

 

Was the desk in full or partial mode ?

 

Were you using palettes when programming the movers or adjusting the parameters directly with the control wheels ?

 

Generic memorys ? - but you said you programmed the generic data directly onto the submasters - not transferred a memory :?

Share this post


Link to post
Share on other sites

Page one, subs 1 to 6 had generic data programmed straight to them.

Turned the desk off, returned turned the desk back on and started to program the movers via the control wheels directly to the subs, page one sub 7 to 12, and pages 2 &3 subs 1 to 12.

When finished went to play back the subs, all fine but for the generic data on page one subs 1 to 6. All the generic stuff had been replaced with the last programmed mover look. ie what was in sub 12 page 3 had recorded its self onto page 1 subs 1 to 6.

Before programming all the subs, memorys, pallets were wiped clean. I recorded the generic data over the affected subs again and it worked fine, weird.

Share this post


Link to post
Share on other sites

That certainly is weird 8O

 

Have you been able to reproduce this fault or did it appear just the once ?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.