Palette Update Bug?

Hi David,

I have had several ocassions where if you update and clear too quickly, the palette doesn't always update. This generally happens with a palette that contains more than one parameter - i.e. PB.

What I got into the habit of doing was Updating, then hitting Blind - if the lamp(s) I was changing moved back to their old values I would know that the Update hadn't taken. Come out of Blind and hit 'Update' and the Update 'takes'.

The other cure seems to be Update - PAUSE (to let the system refresh) - then hit Clear.

I have seen this for a while now - and have flagged it previously. As I said, it generally happens with a Palette with more than one Parameter Mask. Once it starts happenning, it pretty much continues with your show.

Any news on this, Chris / Brad?

Best Wishes,

Pryderi

Dave,

You mention "several software versions" Have you seen the problem with both the cue and the palette being selected on v2.3.1? We fixed this bug that did exist in v2.3.0. Are you updating a reference palette or a normal palette?

I have been reading bug #7977 which seems like it might be related to the problem you describe. I think it is related as Pryderi states with having more than one parameter mask and also multiple fixtures in the palette. I have added your comments to the bug.

This bug is currently targeted for a future release. Can you please send me your show file at: upload.highend.com and also let me know which cuelist and palette you saw this problem with?

thanks,
BRAD

hi Brad,

Will email you my show file, and yes, I've seen it with 2.3.1 on the Full Boar. As it was last week I can't quite remember specifically which lamps I saw the problem with, but almost certainly the VL1000s.

Will forward further details when I return to the show next week.

David

Hi Brad,

I saw this last week on v2.3.1 - the failure to Update that is. Pallettes were Non Referenced.

Best Wishes,

Pryderi

I'm still seeing the bug too - although the work around is to made your changes, hit "clear" then "pig+clear" and the update will then work perfectly.

I can't wait to try this workaround.......by hitting BLIND or the CLEAR, PIG CLEAR.

I have been suffering this bug since the first time I used a hog3 in 2004.
My workaround was to merge directly into pallettes.

But it is essential that this bug is fixed. So that the auto-update will correctly apply changed values to their corresponding pallettes, cues or tracking.

This is the fastest way to program on a schedule.
Once you can trust this function - you can trust the desk.

I'm sure that we had an identical bug on the Hog2.

I see something similar to this with the current release build where sometimes the update does not perform after slecting new information from a palette. Selecting the same information from the wheelset or slot toolbar (ie hard values) removes the issue, but then the cue is no longer referencing the palette. This only appears to apply to update, as using merge does not appear to create the ssue. This whole thing appears to be random and is hard to repro reliably, but will occur once in every 10 updates.

Ross

Thanks Ross.

I have updated your information into the bug mentioned in this thread.

I work with an Road Hog with 40 VL 2500's on sofware version 3.0.1.

I have exactly the same problem.

When comes a bugfix that solved this problem?

Thanx!

Bug 7977 is still targeted for an upcoming major release... I dont have a current release date right now, but this bug is on the list...

Hi using version 3.0.5 (b2482),

Having just bought a Roadhog Fullboar and you are telling me this desk can't simply update a pallete. I have also discovered today the comment macros don't work when you run midi timecode. I'm not at all impressed. The former is a fundamental requirement of any modern lighting desk. please advise when this will be fixed.

Unimpressed!

Nigel Catmur

Nigel,

You said "I have also discovered today the comment macros don't work when you run midi timecode."

Could you please elaborate on this problem and/or send me your show file via our uploader at upload.highend.com

thanks,

Hi Brad,

Thanks for the response. I'm getting slightly desperate here. The issue is with comment macros when running timecode. Below is an email which I sent to Jens Hillskotter. I shall upload the show now on th uploader.

In short I run the main show on fader 10 (previously 8 on the hog2) and the media on fader 9 (prev 7). The two masters are kept in sync with comment macros but currently the commands from fader 10 seem to create the equivalent of a double hit of Go on fader 9. I have created some work rounds using the GM/XXX commands in many places but in places this fails to work as the GM/XXXX seems to have the effect of stomping the list which renders fades over fades useless.

I really hope you can help me with this. We are in rehearsals Wed/Thu/Frid and then the show goes off on tour on over the weekend. I currently have 3 separate productions of this show runnning (West End plus 2 European Tours ) and it may well expand further. 2 are on a Hog2 but I really want to move them over to H3 platform if we can solve this problem.

Below is email to Jens.

========================================
Hi Jens,

I have some more questions / problems I am hoping that you can solve for me.

The show I am working with and transferring from Hog 2 to Roadhog Full Boar is a complicated show and though it does not have many fixtures the programming is very intricate.

On the Hog 2 I have implemented the system to work as follows.

On the template page I have:
fader 8 (cue list) which controls the lighting.
fader 7 which controls the media servers and
fader 6 which receives the timecode.

The show is over 500 cues long and changes pages several times. All the controlling of the sequence of the show comes from fader 8 using comment macros. This is because it puts the show down to a one button operation. Fader 8 then drives fader 7 at the relevant cue points via the comment macros and changes pages and triggers chases etc etc. When there is timecode running fade 8 triggers a go on fader 6 which then listens for the timecode. Fader 6 then drives fader 8 using comment macros. I have achieved this very successfully with the HOG2. I know it all seems very complicated but if the timecode drops out for any reason the operator simply carries on pressing the go on 8 and the show does not suffer.

So..... moving to the Roadhog Fullboar.

I wanted to effectively setup the same system and it seemed this would be easy to do as from the specification the desk should be able to achieve this. However after playing with the desk and timecode I decided that I could simplify things by getting rid of the fader 6 and having the timecode values actually entered in the fader 8 cues. This is because of the enable timecode feature which could be macro triggered. So I entered all the timecode into fade 8 and discovered that the comment macros are unreliable when the cue list is being driven by timecode (MIDI). A simple GM7 command seems to send the media stack to any cue it likes rather than simply being the equivalent of just pressing GO on fader 7. This is also true of the GL commands. So I tried entering GM9/50 type commands to force it to the correct Cue point but this has the effect of stomping the cue list and losing rendering the intricate overfades useless.

I have also tried running from internal Simlulate Timecode to the same effect.

Do you know about these problems and is there a solution.

My criteria is that the show must be able to continue on a single Go button if timecode drops out.

Look forward to hearing.

Nigel.

==============================================

Nigel,

Thanks for the further information... we are looking into this now and will contact you soon.