Loading times

[ice]

I'm working on a somewhat standard showfile for our rig. I've programmed about 200kb of data into my show, everything works fine. The issue is that when I re-program for instance a position pallet, the console starts saving the show again. That fine, but it takes about a minute or so, and it happens every 2 or 3 times I alter something. No need to tell you that's rather annoying. Is there any way to prevent this? I've already disabled the autosave, but that doesn't seem to help a bit.

[Paul]

What do you mean by "disabled the autosave"? Which menu did you use to do this?

[ice]

Ah eeeh, good question. I think I meant the recovery mode, but that of course has rather little to do with it. Problems remains though

[Paul]

Recovery mode only stores the following states:

 

- current screen

- current and next memory numbers

- submaster page and overlay

- SX button states (Mambo only)

 

When you are editing memories/submasters/SXs/palettes, the changes are stored in a battery backed RAM inside the desk. When this buffer fills up, the desk flushes the changes to internal FLASH memory, which is when you see the "saving show please wait" message.

 

When you edit a palette, this can result in changes to alot of data, which would quickly fill up the RAM buffer and force the flush to FLASH memory.

[ice]

That might be the problem... to avoid a lot of work I programmed position pallets, and used those in the scenes/chases. So there's about 15 pallets used in over 50 scenes and chases... Changing one pallet could indeed alter some more scenes and chase-steps, therefore filling the RAM and the desk would flush it...

 

So if I get where you're going there's really nothing I can do to prevent this? It really sucks because actions which would normally take about 10 minutes now take a good half hour because of all the flushing.

[ice]

Any idea on a way to prevent this from happening? Maybe somekind of clever programming style?

[Paul]

Extract from the specification:

 

>>>>>>>>

Clearing Referenced Palettes

If fixture data programmed in a palette is changed to “unprogrammed†or a palette is cleared – for any memories / submasters / SXs which referenced the data in the palette – the palette reference will be replaced by the actual DMX value in the palette before the data in the palette is cleared.

<<<<<<<<

 

This is the reason that the desk needs to check all memories / submasters / SXs when a palette is reprogrammed, which then causes the RAM buffer to be filled up quickly. I can't immediately think of a way of programming around this I'm afraid.

 

However if you could propose an alternative behaviour to that described above, for when referenced palettes are reprogrammed, then it might get looked at in a future software release. Perhaps memories / submasters / SX's could be ignored when palettes are reprogrammed, and if you delete something from a palette that was referenced elsewhere, it's just tough luck, and nothing will be output when that memory / submaster / SX is replayed. Would this be acceptable, or seen as a bug?

[Laubfrosch]

Hi Paul,

 

hmmmmmm :?: :!:

 

I think killing the relation between memories and palettes, is a downgrade and makes the palette to a "live edit function" only.

 

Please keep the software in it´s specs as it is.

 

cheers

 

Sven

 

P.S.: A happy nu 2k5 to all frogfreaks!!!

[ice]

If I get this right the console works like this:

 

- you program a pallet

- you program that pallet into a memory, the desk knows that and programs a reference to that pallet, as well as the pallet values.

- you re-program that same pallet

- the desk starts searching all items for a reference to that pallet and reprograms all items were that reference was found

- you end up waiting.

 

There is a really simple way of avoiding this using OOP;

- program a pallet; the desk makes an instance of a "position" class containing all options at memory address X

- program a memory; the position pallet gets programmed so it contains only a reference to the same instance of "position" (so it points to memory X)

- reprogramming the pallet will update (or overwrite) the instance @ X and therefore update data in all memories.

- at playback time the console gets the references position data (X) and therefore gets updated values.

 

I hope this makes sense? I'm afraid if you didn't program like this a software update wouldn't be possible because that's gonna take loads of work.

 

Maybe you could give us a little explanation of the coding style that was used? Like a sequence diagram or something...

 

Oh; killing that link is no option by the way, it's the only way available to keep your programming clean and simple. Otherwise I should reprogram all memories, and that takes a lot more time than waiting for the buffer to clean out!

[Paul]

The problem is not the data that is in the palette, this is referenced as you say.

 

The problem is the data that might have been removed from the palette. This is why the desk has to search all memories / submasters / SXs that reference the palette.

[ice]

If data was removed from the pallet that was caused by the user pressing "clear" I think? I never do that

 

If it's nicely referenced, updating it would only cause an update of the pallet, so searching isn't necessary at all I think?

[Paul]

Data can be removed from the palette for example by untagging a fixture.

[Kirkup_xp]

In which case, an untagged fixture in a pallet would act as an untagged fixture when programming - ie its outputs wouldn't change with that memory (etc). Surely?

[Paul]

>>>>>>>>

Clearing Referenced Palettes

If fixture data programmed in a palette is changed to “unprogrammed†or a palette is cleared – for any memories / submasters / SXs which referenced the data in the palette – the palette reference will be replaced by the actual DMX value in the palette before the data in the palette is cleared.

<<<<<<<<

[Pipo]

So if you clear your pallettes, the memories made with those pallettes won't change?

And if you reprogram the pallettes, then the memories will change?

Right or wrong?

[Paul]

Correct! Remember to consider palettes on a fixture by fixture basis though.

 

If you remove a fixture from a palette, your memories won't change. If you alter a fixture in a palette, your memories will change.

[LeeStoddart]

>>>>>>>>

Clearing Referenced Palettes

If fixture data programmed in a palette is changed to “unprogrammed†or a palette is cleared – for any memories / submasters / SXs which referenced the data in the palette – the palette reference will be replaced by the actual DMX value in the palette before the data in the palette is cleared.

<<<<<<<<

 

 

 

If I understand the specification you want the result of removing something from a pallette to leave all memories / submasters / SXs in the same state as they would have been had you not made the removal.

 

However, consider the situation where some thing is removed and later re-instated - the link to the palette has been destroyed so any subsequent edits to the pallete won't have effect.

 

Perhaps as an example... we have four fixtures, Colour Palette 1 sets all four fixtures to green, Colour Palette 2 sets all four to blue and Colour Palette 2 sets all four to yellow.

 

If memory 1 sets all four fixtures to open white

memory 2 sets all four to colour palette 1 (green)

memory 3 sets all four to colour palette 2 (blue)

 

If Colour Palette 1 is edited such that the colour is CYAN rather than Green and (by mistake) fixture 4 is untagged the current specification would change memory 2 such that three fixtures referenced colour pallete 1 (cyan) and the fourth fixture had the dmx value for green. Editing the pallete to include fixture 4 will obviously not correct the problem in memory 2 as the reference has been removed.

 

My preference would be that the reference to the pallete be retained but that on execution no output happens (for fixture 4 in this example) That would remove the requirement to look for palette references on changes.

 

Perhaps there could be an option on editing the palette - retain previous effect of removed parameters.

 

Of course it could be possible that there is a bug in the code which is doing this search for references even when the changes made are NEITHER untag NOR clear. :wink:

[Pipo]

Perhaps there could be an option on editing the palette - retain previous effect of removed parameters

 

I think the onboard memory is too small to keep record of all changes.

 

Saving a large showfile takes already enough time.

[ice]

Yeah I don't really know how, but this should be done diferently. For instance the software could check if fixture data was deleted (cleared or untagges), and if not: just alter the pallet and leave the rest alone. I guess that would save some time right? Now you've mentioned that, I don't really know if I programmed everything or just some fixtures in the pallets.

Is there any way to find out which fixture were programmed? If I select all (untagged) fixtures, and bring up a pallet, will only the fixutures affected be tagged again?

[Haytech]

and bring up a pallet, will only the fixutures affected be tagged again?

Happy new year Ice,

No, all fixtures that are tagged will be affected by the pallette call.

I.E. 6 MAC 500 Color is setted to open stored on pallette 1

all Color is setted to red sored on pallette 2

now home color data for all fixtures tag fixture 2, 4, 6 press p2 and violá

Mac 2,4 and 6 are red.

This circumstance is very useful as you can store one pallatte for each color

for all fixtures used.

[ice]

I think you mis-read my question

 

I mean: program a pallet using only fixtures 1&2. Now home data and make sure that no fixtures were tagged. Now select fixtures 1,2&3 and bring up the pallet. Will only fixtures 1&2 be tagged, or will all fixtures be affected? The 3'rd one should also stay at the home parameters right?

[K-Nine]

Frog Reference No 5509 - Updating palettes - "Saving Show Please Wait" message appears frequently when it may not need to - to be investigated.

[ice]

Maybe all the pallets could have a list of items which contain that pallet. That way the console doesn't have to search items that would change, but just look them up in the list.

[Paul]

It's not the searching that takes the time. It's the commiting of memory/submaster/SX edits from the battery backed RAM buffer to the Flash memory if data has been removed from the palette. It might be that the desk is thinking that data has been removed when it hasn't, and is hence making more work for itself than it needs to. This is what we shall investigate.